* 容器 技术 是 继 大 数据 和 云 计算 之 后 又 一 热门 技术 ， 而 且 未 来 相当 一 段 时 间 内 都 会 非常 流行 
“对 IT 从 业者 来 说 ， 掌 握 容器 技术 是 市 场 的 需要 ， 也 是 提升 自我 价值 的 重要 途径 
“每 一 轮 新 技术 的 兴起 ， 无 论 对 公司 还 是 个 人 既是 机 遇 也 是 挑战 
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Kubernetes 是 容器 编排 引擎 的 事实 标准 ， 是 继 大 数据 、 云 计算 和 Docker 之 后 又 一 热门 技术 ， 而 且 未 来 相当 
一 段 时 间 内 都 会 非常 流行 。 对 于 IT 行业 来 说 ， 这 是 一 项 非常 有 价值 的 技术 。 对 于 IT 从 业者 来 说 ， 掌 握 容 器 技术 
既是 市 场 的 需要 ， 也 是 提升 自我 价值 的 重要 途径 。 

本 书 共 15 章 ， 系 统 介绍 了 Kubernetes 的 架构 、 重 要 概念 、 安 装 部 署 方法 、 运 行 管理 应 用 的 技术 、 网 络 存储 
管理 、 集 群 监控 和 日 志 管理 等 重要 内 容 。 书 中 通过 大 量 实 操 案例 深入 浅 出 地 讲解 Kubemetes 核心 技术 ， 是 一 本 
从 入 门 到 进 阶 的 实用 Kubemetes 操作 指导 手册 。 读 者 在 学 习 的 过 程 中 ， 可 以 跟着 教程 进行 操作 ， 在 实践 中 掌握 
Kubemetes 的 核心 技能 。 在 之 后 的 工作 中 ， 则 可 以 将 本 教程 作为 参考 书 ， 按 需 查找 相关 知识 点 。 

本 书 主要 面向 微服 务 软件 开发 人 员 ， 以 及 IT 实施 和 运 维 工 程 师 等 相关 人 员 ， 也 适合 作为 高 等 院 校 和 培训 学 
校 相关 专业 的 教学 参考 书 。 
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写 在 最 前 面 
《每 天 5 分 钟 玩 转 Kubernetes》 是 一 本 系统 学 习 Kubernetes 的 教程 ， 有 下 面 两 个 特点 : 





ө 系统 讲解 当前 最 流行 的 容器 编排 引擎 Kubernetes 

包括 安装 部 署 、 应 用 管理 、 网 络 、 存 储 、 监 控 、 日 志 管理 等 多 个 方面 。 
@。 重 实践 并 兼顾 理论 

通过 大 量 实验 和 操作 带领 大 家 学 习 Kubernetes。 


为 什么 要 写 这 个 


因为 Kubernetes 非常 热门 ， 但 学 习 门 槛 高 。 

2017 年 9 月 ，Mesosphere 宣布 支持 Kubernetes; 10 月 ，Docker 宣布 将 在 新 版 本 中 加 入 对 
Kubernetes 的 原生 支持 。 至 此 ， 容 器 编排 引擎 领域 的 三 足 易 立时 代 结 束 ，Kubernetes 赢得 全 面 胜 
利 。 

其 实 早 在 2015 年 5 月 ，Kubernetes 在 Google 上 的 搜索 热度 就 已 经 超过 了 Mesos 和 Docker 
Swarm, MIB EE ВДЕ, KRF SURT HLEH”. 
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目前 ，AWS、Azure、Google、 阿 里 云 、 腾 讯 云 等 主流 公有 云 提供 的 是 基于 Kubernetes 的 容 
器 服务 。Rancher、CoreOS、IBM、Mirantis、Oracle、Red Hat, VMWare 等 无 数 厂 商 也 在 大 力 研 
发 和 推广 基于 Kubernetes 的 容器 Caas 或 Paas 产品 。 可 以 说 ，Kubernetes 是 当前 容器 行业 最 
热门 的 。 
每 一 轮 新 技术 的 兴起 ， 无 论 对 公司 还 是 个 人 既是 机 会 也 是 挑战 。 这 项 新 技术 未 来 必 将 成 为 主 
流 ， 那 么 作为 IT 从 业者 ， 正 确 的 做 法 就 是 尽快 掌握 。 因 为 : 
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每 天 5 分 钟 玩 转 Kubernetes 


(1) 新 技术 意味 着 新 的 市 场 和 新 的 需求 。 初 期 掌握 这 种 技术 的 人 不 是 很 多 ， 而 市 场 需求 会 越 
来 越 大 ， 因 而 会 形成 供不应求 的 卖方 市 场 ， 物 以 稀 为 贵 ， 这 对 技术 人 员 将 是 一 个 难得 的 价值 提升 
机 会 。 














(2) 学 习 新 技术 需要 时 间 和 精力 ， 早 起 步 早 成 材 。 

机 会 讲 过 了 ， 咱 们 再 来 看 看 挑战 。 

新 技术 往往 意味 着 技术 上 的 突破 和 创新 ， 会 有 不 少 新 的 概念 和 方法 。 

对 于 Kubernetes 这 项 平台 级 技术 ， 覆 盖 的 技术 范围 非常 广 ， 包 括 计算 、 网 络 、 存 储 、 高 可 
用 、 监 控 、 日 志 管 理 等 多 个 方面 ， 要 掌握 这 些 新 技术 对 IT 老兵 尚 有 不 小 难度 ， 更 别 说 新 人 了 。 


写 给 谁 看 

这 套 教程 的 目标 读者 包括 : 

IT 实施 和 运 维 工程 师 

越 来 越 多 的 应 用 将 以 容器 的 方式 在 开发 、 测 试 和 生产 环境 中 运行 。 掌 握 基 于 Kubernetes 的 
容器 平台 运 维 能 力 将 成 为 实施 和 运 维 工程 师 的 核心 竞争 力 。 

软件 开发 人 员 

基于 容器 的 微服 务 架 构 (Microservice Architecture) 会 逐渐 成 为 开发 应 用 系统 的 主流 ， 而 
Kubernetes 将 是 运行 微服 务 应 用 的 理想 平台 ， 市 场 将 需要 大 量具 备 Kubemetes 技能 的 应 用 程序 
开发 人 员 。 

我 自己 

CloudMan 坚信 最 好 的 学 习 方 法 是 分 享 。 编 写 这 本 教程 的 同时 也 是 对 自己 学 习 和 实践 
Кибетеіеѕ 技术 的 总 结 。 对 于 知识 ， 只 有 把 它 写 出 来 并 能 够 让 其 他 人 理解 ， 才 能 说 明 自 己 真正 掌 
RT. 
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先 把 Kubernetes 中 起 来 


Kubernetes (K8s) 是 Google 在 2014 年 发 布 的 一 个 开源 项 目 。 

据说 Google 的 数据 中 心里 运行 着 20 多 亿 个 容器 ， 而 且 Google 十 年 前 就 开始 使 用 容器 
技术 。 

最 初 ，Google 开发 了 一 个 叫 Borg 的 系统 (现在 命名 为 Omega) 来 调度 如 此 庞大 数量 的 
容器 和 工作 负载 。 在 积累 了 这 么 多 年 的 经 验 后 ，Google 决定 重 写 这 个 容器 管理 系统 ， 并 将 其 
贡献 到 开源 社区 ， 让 全 世界 都 能 受益 。 

这 个 项 目 就 是 Kubernetes。 简 单 地 讲 ，Kubernetes 是 Google Omega 的 开源 版 本 。 

从 2014 年 第 一 个 版 本 发 布 以 来 ，Kubernetes 迅速 获得 开源 社区 的 追捧 ， 包 括 Red Hat. 
VMware、Canonical 在 内 的 很 多 有 影响 力 的 公司 加 入 到 开发 和 推广 的 阵营 。 目 前 Kubernetes 
已 经 成 为 发 展 最 快 、 市 场 占有 率 最 高 的 容器 编排 引擎 产品 。 

Kubernetes 一 直 在 快速 地 开发 和 迭代 。 本 书 我 们 将 以 v1.7 和 v1.8 为 基础 学 习 
Kubernetes。 我 们 会 讨论 Kubernetes 重要 的 概念 和 架构 ， 学 习 Kubernetes 如 何 编排 容器 ， 包 
括 优 化 资源 利用 、 高 可 用 、 滚 动 更 新 、 网 络 插件 、 服 务 发 现 、 监 控 、 数 据 管理 、 日 志 管 理 等 。 

下 面 就 让 我 们 开始 Kubernetes 的 探险 之 旅 。 




















先 跑 起 来 


按照 一 贯 的 学 习 思路 , 我 们 会 在 最 短 时 间 内 搭建 起 一 个 可 用 系统 , 这 样 就 能 够 尽快 建立 起 
对 学 习 对 象 的 感性 认识 。 先 把 玩 起 来 ， 快 速 了 解 基本 概念 、 功 能 和 使 用 场景 。 

越 是 门槛 高 的 知识 , 就 越 需要 有 这 么 一 个 最 小 可 用 系统 。 如果 直 接 上 来 就 学 习 理论 知识 和 

念 ， 很 容易 从 入 门 到 放弃 。 

当然 ， 要 搭建 这 么 一 个 可 运行 的 系统 通常 也 不 会 太 容易 ， 不 过 很 幸运 ，Kubernetes 官网 
已 经 为 大 家 准备 好 了 现成 的 最 小 可 用 系统 。 

kubernetesio 开发 了 一 个 交互 式 教程 ， 通 过 Web 浏览 器 就 能 使 用 预先 部 署 好 的 一 个 
Kubernetes 集群 ， 快 速 体验 Kubernetes 的 功能 和 应 用 场景 ， 下 面 我 就 带 着 大 家 去 玩 一 下 。 

打开 https://kubernetes.io/docs/tutorials/kubernetes-basics/。 


页 面 左边 就 能 看 到 教程 菜单 ， 如 图 1-1 所 示 。 
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Tutorials 


v Kubernetes Basics 
Overview 
1. Create a Cluster 
2. Deploy an App 
3. Explore Your App 
4. Expose Your App Publicly 
5. Scale Your App 





6. Update Your App 
图 1-1 


教程 会 指引 大 家 完成 创建 Kubernetes 集群 、 部 署 应 用 、 访 问 应 用 、 扩 展 应 用 、 更 新 应 用 
等 最 常见 的 使 用 场景 ， 迅 速 建立 感性 认识 。 








创建 Kubernetes 集群 


点 击 教程 菜单 1. Create a Cluster — Interactive Tutorial - Creating a Cluster, 如 图 1-2 所 示 。 


kubernetes 


Tutorials 


v Kubernetes Basics 





Overview 
v 1. Create a Cluster 
Using Minikube to Create a Cluster 


Interactive Tutorial - Creating a Cluster 


» 2. Deploy an App 


»- 3. Explore Your App 

» 4. Expose Your App Publicly 
» 5. Scale Your App 

» 6. Update Your App 








图 1-2 
显示 操作 界面 ， 如 图 1-3 所 示 。 


рїасе. 





样 就 创建 好 了 





Cluster up and 
running 

We already installed minikube for 
you. Check that it is properly 


installed, by running the minikube 
version command: 


minikube version e 


OK, we can see that minikube is in 


Start the cluster, by running the 
minikube start command: 


minikube start e 


Great! You now have a running 
Kubernetes cluster in your online 
terminal. Minikube started a virtual 
machine for you, and a Kubernetes Keta«oda 


Terminal + 




















Step1of3 


1-3 


左边 部 分 是 操作 说 明 。 右 边 是 Terminal， 即 命令 终端 窗口 。 
按照 操作 说 明 ， 我 们 在 Terminal 中 执行 minikube start， 然 后 执行 kubectl get nodes， 这 


-个 单 节点 的 kubernetes 集群 ， 如 图 1-4 所 示 。 


Terminal 十 


Kubernetes Bootcamp Terminal 
> 


> minikube start 
Starting local Kubernetes cluster... 


> kubectl get nodes 
МАМЕ STATUS AGE 
host91 Ready 7s 


> hostname 
e968725c1697 





814 


集群 的 唯一 节点 为 host01， 需 要 注意 的 是 当前 执行 命令 的 地 方 并 不 是 host01。 我 们 是 通 


过 Kubernetes 的 命令 行 工具 kubectl 远程 管理 集群 。 
执行 kubectl cluster-info 查看 集群 信息 ， 如 图 1-5 所 示 。 


> kubectl cluster-info 
Kubernetes master is running at http: 
heapster is running at http://host01 
kubernetes-dashboard is running at htt 
monitoring-grafana is running at http:/ 


monitoring-influxdb is running at http: 
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 


> 





图 1-5 
heapster、kubernetes-dashboard 都 是 集群 中 运行 的 服务 。 
注意 : 为 节省 篇 幅 ,在 后 面 的 演示 中 ,我们 将 简化 操作 步骤 ,详细 的 说 明和 完整 步骤 请 参 
考官 网 在 线 文档 。 





执行 命令 : 


kubectl run kubernetes-bootcamp V 
--image-docker.io/jocatalin/kubernetes-bootcamp:vl \ 
--port-8080 


这 里 我 们 通过 kubectlrun 部 署 了 一 个 应 用 , 命名 为 kubernetes-bootcamp， 如 图 1-6 所 示 。 
Docker 镜像 通过 --image 指定 。 
--port 设置 应 用 对 外 服务 的 端口 。 
Terminal 中 
> kubectl run kubernetes-bootcamp V 
> —-image-docker.io/jocatalin/kubernetes-bootcamp:v1 N 


> ——port=8080 
deployment "kubernetes-bootcamp" created 





>" 


图 1-6 


这 里 Deployment 是 Kubernetes 的 术语 ， 可 以 理解 为 应 用 。 

Kubernetes 还 有 一 个 重要 术语 Pod。 

Pod 是 容器 的 集合 ， 通 常会 将 紧密 相关 的 一 组 容器 放 到 一 个 Pod 中 ， 同 一 个 Pod 中 的 所 
有 容器 共享 IP 地 址 和 Port 空间 ， 也 就 是 说 它们 在 一 个 network namespace 中 。 

Pod 是 Kubernetes 调度 的 最 小 单位 ， 同 一 Pod 中 的 容器 始终 被 一 起 调度 。 

运行 kubectl get pods， 查 看 当前 的 Pod， 如 图 1-7 所 示 。 











n 





> kubectl get pods 
МАМЕ READY STATUS RESTARTS АСЕ 


kubernetes-bootcamp-390780338-q9p1t 1/1 Running 0 11m 


> 





图 1-7 


kubernetes-bootcamp-390780338-q9plt 就 是 应 用 的 Pod. 





访问 应 用 


默认 情况 下 ， 所 有 Pod 只 能 在 集群 内 部 访问 。 对 于 上 面 这 个 例子 ， 要 访问 应 用 只 能 直接 
访问 容器 的 8080 端口 。 为 了 能 够 从 外 部 访问 应 用 , 我 们 需要 将 容器 的 8080 端口 映射 到 节点 
的 端 





























执行 如 下 命令 ， 结 果 如 图 1-8 所 示 。 


kubectl expose deployment/kubernetes-bootcamp V 
--type-"NodePort" \ 
--port 8080 


» kubectl expose deployment/kubernetes-bootcamp V 
> --type-"NodePort" V 
> --port 8080 


service "kubernetes-bootcamp" exposed 


> 





图 1-8 
执行 命令 kubectl get services， 可 以 查看 应 用 被 映射 到 节点 的 哪个 端口 ， 如 图 1-9 所 示 。 


> kubectl get services 
NAME CLUSTER-IP EXTERNAL-IP — PORT(S) 
kubernetes 10.0.0.1 «none» 443/ТСР 


kubernetes-bootcamp 10.0.0.131 «nodes» 8080:32320/TCP 


> 





图 1-9 
这 里 有 两 个 service， 可 以 将 service 暂时 理解 为 端口 映射 ， 后 面 我 们 会 详细 讨论 。 
Kubernetes 是 默认 的 service, 暂时 不 用 考虑 。kubernetes-bootcamp 是 我 们 应 用 的 service， 
8080 端口 已 经 映射 到 host01 的 32320 端口 ， 端 口号 是 随机 分 配 的 ， 可 以 执行 如 下 命令 访问 
应 用 ， 结 果 如 图 1-10 所 示 。 


curl host01:32320 



























































> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-q9plt | v=1 


> 





图 1-10 














默认 情况 下 应 用 只 会 运行 一 个 副本 ,可 以 通过 kubectl get deployments 查看 副本 数 ， 如 图 
1-11 所 示 。 


> kubectl get deployments 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-bootcamp 1 * 1 1 14m 





图 1-11 
执行 如 下 命令 将 副本 数 增加 到 3 个 ， 如 图 1-12 所 示 。 
kubectl scale deployments/kubernetes-bootcamp --replicas-3 


> kubectl scale deployments/kubernetes-bootcamp —replicas-3 
deployment "kubernetes-bootcamp" scaled 


> 


> kubectl get deployments 


NAME DESIRED CURRENT  UP-TO-DATE AVAILABLE АСЕ 
kubernetes-bootcamp 3 3 3 З: 17m 


> 





图 1-12 
通过 kubectl get pods 可 以 看 到 当前 Pod 增加 到 3 个 ， 如 图 1-13 所 示 。 


> kubectl get pods 

NAME STATUS RESTARTS 
kubernetes-bootcamp-390780338-12sbg Running 
kubernetes-bootcamp-390780338-q9p1t Running 


kubernetes-bootcamp-390780338-swvp7 Running 


> 





图 1-13 


通过 curl 访问 应 用 ， 可 以 看 到 每 次 请 求 发 送 到 不 同 的 Pod，3 个 副本 轮 询 处 理 ， 这 样 就 
实现 了 负载 均衡 ， 如 图 1-14 所 示 。 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-12sbg | 


> curl host81:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-swvp7 | 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-q9plt | 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-12sbg | 





图 1-14 
要 scale down 也 很 方便 ， 执 行 下 列 命令 ， 结 果 如 图 1-15 所 示 。 
kubectl scale deployments/kubernetes-bootcamp --replicas-2 


> kubectl scale deployments/kubernetes-bootcamp —replicas-2 
deployment "kubernetes-bootcamp" scaled 


> kubectl get deployments 
NAME DESIRED CURRENT  UP-TO-DATE AVAILABLE AGE 
kubernetes-bootcamp 2 2 2 25m 


> kubectl get pods 

NAME STATUS RESTARTS 
kubernetes-bootcamp-390780338-12sbg Running ° 
kubernetes-bootcamp-390780338-q9p1t Running 9 
kubernetes-bootcamp-390780338-swvp7 Terminating | 0 





图 1-15 
从 图 1-15 中 可 以 看 到 ， 其 中 一 个 副本 被 删除 了 。 





滚动 更 新 


当前 应 用 使 用 的 image 版 本 为 v1， 执 行 如 下 命令 将 其 升级 到 v2， 结 果 如 图 1-16 所 示 。 


kubectl set image deployments/kubernetes-bootcamp 
kubernetes-bootcamp-jocatalin/kubernetes-bootcamp:v2 


> kubectl set image deployments/kubernetes-bootcamp kubernetes-bootca 
deployment "kubernetes-bootcamp" image updated 


> kubectl get pods 
МАМЕ STATUS RESTARTS 
kubernetes-bootcamp-2100875782-2q5k8 ContainerCreating @ 
kubernetes-bootcamp-2100875782-sbwkc ContainerCreating © 
kubernetes-bootcamp-390780338-12sbg Terminating ° 
kubernetes-bootcamp-390780338-q9p1t Running ° 


> kubectl get pods 
NAME STATUS RESTARTS 
kubernetes-bootcanp-2108875782-2q5k8 Running e 
kubernetes-bootcamp-2100875782-sbwkc Running e 
kubernetes-bootcamp-390780338-12sbg Terminating @ 
kubernetes-bootcamp-390780338-q9pit Terminating ё 


> kubectl get pods 
NAME STATUS RESTARTS 
kubernetes-bootcamp-2100875782-2q5k8 Running e 
kubernetes-bootcamp-2100875782-sb«kc Running ё 





图 1-16 


通过 kubectl get pods 可 以 观察 滚动 更 新 的 过 程 : vl 的 Pod 被 逐个 删除 ， 同 时 启动 了 新 
的 v2 Pod。 更 新 完成 后 访问 新 版 本 应 用 ， 如 图 1-17 所 示 。 





> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-2100875782-sbwkc | v=2 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-2100875782-205k8 | v=2 





> 


图 1-17 
如 果 要 回 退 到 vl 版 本 也 很 容易 ， 执 行 kubectlrollout undo 命令 ， 结 果 如 图 1-18 所 示 。 





kubectl rollout undo deployments/kubernetes-bootcamp 


» kubectl rollout undo deployments/kubernetes-bootcamp 
deployment "kubernetes-bootcamp" rolled back 


> kubectt get pods 

NAME STATUS RESTARTS АСЕ 
kubernetes-bootcamp-2100875782-2q5k8 Running ° 7n 
kubernetes-bootcamp-2100875782-sbwkc Terminating ° 7n 
kubernetes-bootcamp-390780338-9kvj j ContainerCreating ө 5s 
kubernetes-bootcamp-390780338-hmcgb ContainerCreating @ 55 





图 1-18 
验证 版 本 已 经 回 退 到 v1， 如 图 1-19 所 示 。 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-hmcgb | v=1 





> curl host01:32320 


Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-9kvjj | v=1 





图 1-19 





至 此 ， 我 们 已 经 通过 官网 的 交互 式 教程 快速 体验 了 Kubernetes 的 功能 和 使 用 方法 。 本 书 
的 其 余 章 节 将 详细 讨论 Kubernetes 的 架构 、 典 型 的 部 署 方法 、 容 器 编排 能 力 、 网 络 方案 、 监 
控 方案 ， 帮 助 大 家 全 面 掌握 Kubernetes 的 核心 技能 。 














第 2 
ESHE 


在 实践 之 前 ， 必 须 先 学 习 Kubernetes 的 几 个 重要 概念 ， 它 们 是 组 成 Kubernetes 集群 的 
基石 。 

1. Cluster 

Cluster 是 计算 、 存 储 和 网 络 资源 的 集合 ，Kubernetes 利用 这 些 资源 运行 各 种 基于 容器 的 
应 用 。 

2. Master 

Master 是 Cluster 的 大 脑 , 它 的 主要 职责 是 调度 , 即 决定 将 应 用 放 在 哪里 运行 。Master 运 
17 Linux 操作 系统 ， 可 以 是 物理 机 或 者 虚拟 机 。 为 了 实现 高 可 用 ， 可 以 运行 多 个 Master. 








3. Node 

Node 的 职责 是 运行 容器 应 用 。Node 由 Master 管理 , Node 负责 监控 并 汇报 容器 的 状态 ， 
同时 根据 Master 的 要 求 管理 容器 的 生命 周期 。Node 运行 在 Linux 操作 系统 上 , 可 以 是 物理 
机 或 者 是 虚拟 机 。 


在 前 面 交 互 式 教程 中 ， 我 们 创建 的 Cluster 只 有 一 个 主机 host01， 它 既是 Master 也 是 
Node， 如 图 2-1 所 示 。 


Terminal + 


Kubernetes Bootcamp Terminal 
> 


> minikube start 
Starting local Kubernetes cluster... 


> kubectt get nodes 
NAME STATUS AGE 
hostel Ready 75 


> hostname 
e968725c1697 


> 





图 2-1 


4. Pod 
Pod 是 Kubernetes 的 最 小 工作 单元 。 每 个 Pod 包含 一 个 或 多 个 容器 。Pod 中 的 容器 会 
作为 一 个 整体 被 Master 调度 到 一 个 Node 上 运行 。 





Kubernetes 引入 Pod 主要 基于 下 面 两 个 目的 : 


(1) 可 管理 性 。 
有 些 容器 天 生 就 是 需要 紧密 联系 ， 一 起 工作 。Pod 提供 了 比 容器 更 高 层次 的 抽象 ， 将 它 
们 封装 到 一 个 部 署 单元 中 。Kubernetes 以 Pod 为 最 小 单位 进行 调度 、 扩 展 、 共 享 资源 、 管 理 
生命 周期 。 


QD 通信 和 资源 共享 。 

Pod 中 的 所 有 容器 使 用 同一 个 网 络 namespace， 即 相同 的 IP 地 址 和 Port 空间 。 它 们 五 
以 直接 用 localhost 通信 。 同 样 的 ， 这 些 容 器 可 以 共享 存储 ， 当 Kubernetes 挂 载 volume 到 
Pod， 本 质 上 是 将 volume 挂 载 到 Pod 中 的 每 一 个 容器 。 

Pods 有 两 种 使 用 方式 : 

(1) 运行 单一 容器 。 

one-container-per-Pod 是 Kubernetes 最 常见 的 模型 ， 这 种 情况 下 ， 只 是 将 单个 容器 简单 
封装 成 Pod。 即 便 是 只 有 一 个 容器 ，Kubernetes 管理 的 也 是 Pod 而 不 是 直接 管理 容器 。 

(2) 运行 多 个 容器 。 

问题 在 于 : 哪些 容器 应 该 放 到 一 个 Pod 中 ? 

答案 是 : 这 些 容 器 联系 必须 非常 紧密 ， 而 且 需 要 直接 共享 资源 。 

举 个 例子 , 如 图 2-2 所 示 , 这 个 Pod 包含 两 个 容器 : 一 个 是 File Puller, 一 个 是 Web Server. 



































Content 
Manager 





图 2-2 


File Puller 会 定期 从 外 部 的 Content Manager 中 拉 取 最 新 的 文件 ， 将 其 存放 在 共享 的 
volume 中 。Web Server 从 volume 读 取 文件 ， 啊 应 Consumer 的 请 求 。 

这 两 个 容器 是 紧密 协作 的 ， 它 们 一 起 为 Consumer 提供 最 新 的 数据 ; 同时 它们 也 通过 
volume 共享 数据 ， 所 以 放 到 一 个 Pod 是 合适 的 。 

再 来 看 一 个 反例 : 是 否 需 要 将 Tomcat 和 MySQL 放 到 一 个 Pod 中 ? 

Tomcat 从 MySQL 读 取 数据 ， 它 们 之 间 需 要 协作 ， 但 还 不 至 于 需要 放 到 一 个 Pod 中 一 
起 部 署 、 一 起 启动 、 一 起 停止 。 同 时 它们 之 间 是 通过 JDBC 交换 数据 ， 并 不 是 直接 共享 存储 ， 
所 以 放 到 各 自 的 Pod 中 更 合适 。 





5. Controller 

Kubernetes 通常 不 会 直接 创建 Pod， 而 是 通过 Controller 来 管理 Pod 的 。Controller 中 
定义 了 Pod 的 部 署 特 性 ， 比 如 有 几 个 副本 、 在 什么 样 的 Node 上 运行 等 。 为 了 满足 不 同 的 业 
务 场景 ，Kubernetes 提供 了 多 种 Controller， 包 括 Deployment、ReplicaSet、DaemonSet、 
StatefuleSet, Job 等 ， 我 们 逐一 讨论 。 


(1) Deployment 是 最 常用 的 Controller， 比 如 在 线 教 程 中 就 是 通过 创建 Deployment Ж 
部 署 应 用 的 。Deployment 可 以 管理 Pod 的 多 个 副本 ， 并 确保 Pod 按照 期 望 的 状态 运行 。 
(2)ReplicaSet 实现 了 Pod 的 多 副本 管理 。 使 用 Deployment 时 会 自动 创建 ReplicaSet, 
也 就 是 说 Deployment 是 通过 ReplicaSet 来 管理 Pod 的 多 个 副本 的 , 我 们 通常 不 需要 直接 使 
Н ReplicaSet。 

(3) DaemonSet 用 于 每 个 Node 最 多 只 运行 一 个 Pod 副本 的 场景 。 正 如 其 名 称 所 揭示 
“J, DaemonSet 通常 用 于 运行 daemon. 

(4) StatefuleSet 能 够 保证 Pod 的 每 个 副本 在 整个 生命 周期 中 名 称 是 不 变 的 ， 而 其 他 
Controller 不 提供 这 个 功能 。 当 某 个 Pod 发 生 故 障 需要 删除 并 重新 启动 时 ，Pod 的 名 称 会 发 
生变 化 ， 同 时 StatefuleSet 会 保证 副本 按照 固定 的 顺序 启动 、 更 新 或 者 删除 。 

C5) Job 用 于 运行 结束 就 删除 的 应 用 ， 而 其 他 Controller 中 的 Pod 通常 是 长 期 持续 运行 。 

6. Service 

Deployment 可 以 部 署 多 个 副本 ， 每 个 Роа 都 有 自己 的 了 P， 外 界 如 何 访问 这 些 副本 呢 ? 

通过 Pod 的 IP 吗 ? 

要 知道 Pod 很 可 能 会 被 频繁 地 销毁 和 重启 ， 它 们 的 IP 会 发 生变 化 , 用 IP 来 访问 不 太 
现实 。 

答案 是 Service。 

Kubernetes Service 定义 了 外 界 访问 一 组 特定 Pod 的 方式 。Service 有 自己 的 1Р 和 端口 ， 
Service 为 Pod 提供 了 负载 均衡 。 

Kubernetes 运行 容器 (Pod) 与 访问 容器 (Pod) 这 两 项 任务 分 别 由 Controller 和 Service 
执行 。 

7. Namespace 

如 果 有 多 个 用 户 或 项 目 组 使 用 同一 个 Kubernetes Cluster， 如 何 将 他 们 创建 的 Controller、 
Pod 等 资源 分 开 呢 ? 
答案 就 是 Namespace。 

Namespace 可 以 将 一 个 物理 的 Cluster 逻辑 上 划分 成 多 个 虚拟 Cluster， 每 个 Cluster 就 
-个 Namespace。 不 同 Namespace 里 的 资源 是 完全 隔离 的 。 
Kubernetes 默认 创建 了 两 个 Namespace， 如 图 2-3 所 示 。 
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> kubectl get namespace 
NAME STATUS AGE 
default Active 17s 


kube-system Active 175 





图 2-3 


default: 创建 资源 时 如 果 不 指定 ， 将 被 放 到 这 个 Namespace 中 。 
kube-system: Kubernetes 自己 创建 的 系统 资源 将 放 到 这 个 Namespace 中 。 





本 章 我 们 将 部 署 三 个 节点 的 Kubernetes Cluster， 如 图 3-1 所 示 。 


enp0s8 
192.168.56.105 í k8s-master 





enp0s8 
192.168.56.106 ( k8s-node1 ) 


enp0s8 
192.168.56.107 (k8s-node2 ) 





3-1 
k8s-master 是 Master, k8s-nodel 和 k8s-node2 是 Node. 
所 有 节点 的 操作 系统 均 为 Ubuntu 16.04， 当 然 其 他 Linux 也 是 可 以 的 。 
官方 安装 文档 可 以 参考 https://kubernetes.io/docs/setup/independent/install-kubeadm/. 
注意 : Kubernetes 几乎 所 有 的 安装 组 件 和 Docker 镜像 都 放 在 Google 自己 的 网 站 上 , 这 








AR 
H 


Еру ЙА] Н AEEA ENE: 网 络 障碍 都 必须 想 办 法 克服 , 不然 连 Kubernetes 
的 门 都 进 不 了 。 











安装 Docker 


所 有 节点 都 需要 安装 Docker。 


apt-get update && apt-get install docker.io 


安装 kubelet、kubeadm 和 kubectl 


在 所 有 节点 上 安装 kubelet、kubeadm 和 kubectl。 


€  kubelet 运行 在 Cluster 所 有 节点 上 ， 负 责 启 动 Pod 和 容器 。 

€  kubeadm 用 于 初始 化 Cluster, 

€ kubectl 是 Kubernetes 命令 行 工 具 。 通过 kubectl 可 以 部 署 和 管理 应 用 ， 查 看 各 种 资 
源 ， 创 建 、 删 除 和 更 新 各 种 组 件 。 

apt-get update && apt-get install -у apt-transport-https 

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - 

cat <<ЕОЕ »/etc/apt/sources.list.d/kubernetes.list 

deb http://apt.kubernetes.io/ kubernetes-xenial main 

EOF 

apt-get update 

apt-get install -y kubelet kubeadm kubectl 


用 kubeadm 创建 Cluster 


完整 的 官方 文档 可 以 参考 https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/. 


3.34 初始 化 Master 
在 Master 上 执行 如 下 命令 : 


kubeadm init --apiserver-advertise-address 192.168.56.105 
--pod-network-cidr-10.244.0.0/16 




















—apiserver-advertise-address 指明 用 Master 的 哪个 interface 与 Cluster 的 其 他 节点 通 
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信 。 如 果 Master 有 多 个 interface， 建议 明确 指定 ， 如 果 不 指 定 ，kubeadm 2: А IERA SKU 
网 关 的 interface。 
--pod-network-cidr 指定 Pod 网 络 的 范围 。Kubernetes 支持 多 种 网 络 方案 , 而 且 不 同 网 络 
方案 对 --pod-network-cidr 有 自己 的 要 求 ， 这 里 设置 为 10.244.0.0/16 是 因为 我 们 将 使 
flannel 网 络 方案 ， 必 须 设置 成 这 个 CIDR。 在 后 面 的 实践 中 我 们 会 切换 到 其 他 网 络 方案 ， 比 
如 Canal。 
初始 化 过 程 如 图 3-2 所 示 。 


root@k8s -maste 
root@k8s-master:~# kubeadm init --apiserver-advertise-address 192.168.56.105 --pod-network-cidr-10.244. 
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters. 
[init] Using Kubernetes version: v1.7.4 
[init] Using Authorization modes: [Node RBAC] 
[preflight] Running pre-flight checks 
[preflight] Starting the kubelet service 
[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0) 
[certificates] Generated CA certificate and key. 
[certificates] Generated API server certificate and key 
[certificates] API Server serving cert is signed for DNS names [kBs-master kubernetes kubernetes.defoult kubernetes.default.svc kubernetes. 
96.0.1 192.168.56.105] 
[certificates] Generated API server kubelet client certificate ond key 
Generated service account token signing key ond public key 
Generated front-proxy CA certificate and key 
Generated front-proxy client certificate ond key 
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki" 






































[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/odmin. conf" 
[kubeconfig] Wrote KubeConfig file to disk: " ernetes/kubelet . conf" 
[kubeconfig] Wrote KubeConfig file to disk kubernetes/controller-manager. conf" 
[kubeconfig] Wrote KubeConfig file to disk: " 'ubernetes/schedul 

[apiclient] Created API client, waiting for the control plane to be 

[apiclient] All control plane components are healthy after 26.505992 seconds 


[token] Using token: d38a01.13653e584ccc1980 
[apiconfig] Created КВАС rules 

[addons] Applied essential oddon: kube-proxy 
[addons] Applied essential addon: kube-dns 


Your Kubernetes master has initialized successfully! 
To start using your cluster, you need to run Соз a regular user) 
mkdir -p $HOME/.kube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $Cid -u):$Cid -9) $HOME/.kube/config 
You should now deploy a pod network to the cl 
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at 


http://kubernetes. io/docs/admin/addons/ 


You сап now join any number of machines by running the following оп each node 
las root: 


kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 


root@k8s-master:~# 





图 3-2 


(1) kubeadm 执行 初始 化 前 的 检查 。 

(2) 生成 token 和 证 书 

(3) 生成 KubeConfig 文件 ，kubelet 需要 用 这 个 文件 与 Master 通信 。 

(4) 安装 Master 组 件 ， 会 从 Google 的 Registry 下 载 组 件 的 Docker 镜像 。 这 一 步 可 
能 会 花 一 些 时 间 ， 主 要 取决 于 网 络 质 量 。 

(5) 安装 附加 组 件 kube-proxy 和 kube-dns。 

(6) Kubernetes Master 初始 化 成 功 。 

(7) 提示 如 何 配 置 kubectl， 后 面 会 实践 。 

(8) 提示 如 何 安装 Pod 网 络 ， 后 面 会 实践 。 
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(9) 提示 如 何 注册 其 他 节点 到 Cluster， 后 面 会 实践 。 


3.3.2 配置 kubectl 


kubectl 是 管理 Kubernetes Cluster 的 命令 行 工具 ， 前 面 我 们 已 经 在 所 有 的 节点 安装 了 
kubectl。Master 初始 化 完成 后 需要 做 一 些 配置 工作 ， 然 后 kubectl 就 能 使 用 了 。 

依照 kubeadm init 输出 的 第 7 步 提 示 ， 推 荐 用 Linux 普通 用 户 执行 kubectl (root 会 有 
- 些 问题 ) 。 

我 们 为 用 户 ubuntu 配置 kubectl: 

su - ubuntu 

mkdir -p $HOME/.kube 


sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $(id -u):$(id -g) $HOME/.kube/config 


为 了 使 用 更 便捷 ， 启 用 kubectl 命令 的 自动 补 全 功能 : 
echo "source «(kubectl completion bash)" >> -/.bashrc 


这 样 ， 用 户 ubuntu 就 可 以 使 用 kubectl 了 。 


3.3.3 安装 Pod 网 络 
要 让 Kubernetes Cluster 能 够 工作 ， 必 须 安装 Pod Pdf, iU Роа 之 间 无 法 通信 。 
Kubernetes 支持 多 种 网 络 方案 ， 这 里 我 们 先 使 用 flannel， 后 面 还 会 讨论 Canal. 
执行 如 下 命令 部 署 flannel， 如 图 3-3 所 示 。 


kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/ 
Documentation/kube-flannel.yml 


ubuntuékBs-master:-$ 

ubuntuékBs-master:-$ kubectl apply -f https://row.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel. yml 
clusterrole "flannel" created 

clusterrolebinding "flannel" created 


serviceaccount "flannel" created 
configmap "kube-flannel-cfg" created 
daemonset "kube-flannel-ds" created 
ubuntuék8s-master:-$ 





图 3-3 


3.3.4 添加 k8s-node1 和 k8s-node2 
在 k8s-nodel 和 k8s-node2 上 分 别 执行 如 下 命令 ， 将 其 注册 到 Cluster 中 : 


kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 


这 里 的 --token 来 自前 面 kubeadm init 输出 的 第 9 步 提示 ， 如 果 当 时 没有 记录 下 来 ， 可 
以 通过 kubeadm token list 查看 ， 如 图 3-4 所 示 。 
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гоо+@к85-таз+ег:—# 
root@k8s-master:~# kubeadm token list 


TOKEN TTL EXPIRES USAGES DESCRIPTION 
d38a01.13653e584ccc1980 <forever> <never> authentication,signing The default bootstrap token generated by 'kubeadm init'. 
rootek8s-master :—# 
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kubeadm join 执行 如 图 3-5 所 示 。 


root@k8s-node1:~# 
rooték8s-nodel:-f kubeadm join --token d38001.13653e584ccc1980 192.168.56.105:6443 
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters. 
Running pre-flight checks 
Starting the kubelet service 
Trying to connect to API Server "192.168.56.105:6443" 
Created cluster-info discovery client, requesting info from "https://192.168.56.105:6443" 
Cluster info signature and contents are valid, will use API Server "http: /192.168.56.105:6443" 
Successfully established connection with API Server "192.168.56.105:6443 
Detected server version: v1.7.4 
The server supports the Certificates API (certificotes.k8s, io/vibetal) 
[csr] Created API client to obtain unique certificate for this node, generating keys and certificate signing request 
[csr] Received signed certificate from the API server, generating KubeConfig... 
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf" 


Node join complete: 

* Certificate signing request sent to master and response 
received. 

* Kubelet informed of new secure connection details 


Run 'kubectl get nodes' on the master to see this machine join. 
rooték8s-node1 :-& 





图 3-5 
根据 提示 ， 我 们 可 以 通过 kubectl get nodes 查看 节点 的 状态 ， 如 图 3-6 所 示 。 


ubuntu@k8s-master:~$ kubectl get nodes 
NAME STATUS AGE VERSION 
k8s-master NotReady 45m v1.7.4 


k8s-nodel ^ NotReady 595 v1.7.4 
k8s-node2 _ NotReady 6s v1.7.4 


图 3-6 

目前 所 有 节点 都 是 NotReady， 这 是 因为 每 个 节点 都 需要 启动 若干 组 件 ， 这 些 组 件 都 是 在 

Pod 中 运行 ， 需 要 首先 从 Google 下 载 镜像 。 我 们 可 以 通过 如 下 命令 查看 Pod 的 状态 ， 如 图 
3-7 所 示 。 








kubectl get pod --all-namespaces 


lubuntuek8s-master:-$ kubectl get pod --all-namespaces 
NAME READY STATUS RESTARTS 
etcd-k8s-master 1⁄4 Running 
kube-apiserver-k8s-master 1⁄1 Running 
kube-controller-manager-k8s-master 1/1 Running 
kube-dns-2425271678-1z3pv 0/3 Pending 
kube- f Lannel-ds-cqbpb 0/2 ContainerCreating 
kube-flannel-ds-v0p3x 0/2 ImagePullBackOff 
kube-flannel-ds-xk49w 0/2 ContainerCreating 
kube-proxy-16mg9 0/1 ContainerCreating 
kube-proxy-wc4j0 1/1 Running 
kube-proxy-x15gd 0/1 ContainerCreating 
kube-scheduler-k8s-master 1/1 Running 


@ 
0 
9 
o 
o 
@ 
o 
0 
0 
0 





图 3-7 
Pending、ContainerCreating、ImagePullBackOff 都 表明 Pod 没有 就 绪 ，Running 才 是 就 
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绪 状 态 。 我 们 可 以 通过 kubectl describe pod «Pod Name» 查看 Pod 的 具体 情况 ， 比 如 : 


kubectl describe pod kube-flannel-ds-vOp3x --namespace-kube-system 


结果 如 图 3-8 所 示 。 


SubübjectPoth Type Reoson Messoge 





k8s-master Normal SuccessfulMountVolume — MountVolume.SetUp succeeded for volume "cni" 

kBs-moster Normal SuccessfulMountVolume — MountVolume.SetUp succeeded for volume "run 

k8s-master Normal SoccessfulMountVolume — MountVolume.SetUp succeeded for volume "flonnel-cfg" 
k8s-master Normal SuccessfulMountVolume — MountVolume.SetUp succeeded for volume "flonnel-token-l8qv1" 
k8s-master  spec.containers{kube-flannel} Warning Failed Failed to pull imoge "quay. i 


k8s-master ^ spec.conteiners(install-cni) [Í Normal 
маена 
Normal 





这 里 只 截取 命令 输出 的 最 后 部 分 ， 可 以 看 到 在 下 载 image 时 失败 ， 如 果 
网 络 质量 不 好 ， 这 种 情况 是 很 常见 的 。 我 们 可 以 耐心 等 待 ， 因 为 Kubernetes 会 重 试 ， 我 们 也 
可 以 自己 手动 执行 docker pull. 去 下 载 这 个 镜像 。 

等 待 一 段 时 间 ，image 成 功 下 载 后 ， 所 有 Pod 都 会 处 于 Running 状态 ， 如 图 3-9 所 示 。 


ubuntuek8s-master: 

ubuntu@k8s-master:~$ kubectl get pod --all-namespaces 

NAMESPACE МАМЕ READY — STATUS RESTARTS AGE 
kube-system — etcd-k8s-master 1⁄4 Running 
kube-system kube-apiserver-k8s-master 1⁄4 Running 
kube-system — kube-controller-manager-k8s-master 1/1 Running 
kube-system kube-dns-2425271678-1z3pv 3⁄3 Running 
kube-system ^ kube-flannel-ds-cqbpb 2⁄2 Running 
kube-system kube-flannel-ds-v@p3x 2⁄2 Running 
kube-system — kube-flannel-ds-xk49w 2/2 Running 
kube-system ^ kube-proxy-16mg9 1⁄4 Running 
kube-system kube-proxy-wc4j0 1/1 Виппїпд 
kube-system — kube-proxy-xl5gd iA Running 
kube-system ^ kube-scheduler-k8s-master 1/1 Running 
ubuntuêk8s-master :~$ 











3-9 
这 时 ， 所 有 的 节点 都 已 经 准备 好 了 ，Kubernetes Cluster 创建 成 功 ， 如 图 3-10 所 示 。 


ubuntuek8s-master: -$ 
ubuntuek8s-master:-$ kubectl get nodes 
INAME STATUS AGE VERSION 
k8s-master Ready 1h v1.7.4 


k8s-node1 Ready 18m v1.7.4 
k8s-node2 Ready 17n v1.7.4 
ubuntuek8s-master: -$ 





图 3-10 


小 结 


本 章 通过 kubeadm 部 署 了 三 节点 的 Kubernetes 集群 ， 后 面 章 节 我 们 将 在 这 个 实验 环境 
中 学 习 Kubernetes 的 各 项 技术 。 
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Kubernetes Cluster 由 Master 和 Node 组 成 ， 节 点 上 运行 着 若干 Kubernetes 服务 。 


4.1 Master 节点 


Master 是 Kubernetes Cluster 的 大 脑 ， 运 行 着 的 Daemon 服务 包括 kube-apiserver、 
kube-scheduler、kube-controller-manager、etcd 和 Pod 网 络 (例如 flannel) ， 如 图 4-1 所 示 。 


© ase 


etcd 


$ flannel 


enp0s8 
192.168.56.105 (k8s-master) 


图 4-1 





1. API Server ( kube-apiserver ) 

API Server 提供 HTTP/HTTPS RESTful API, HJ Kubernetes АРІ. API Server 是 
Kubernetes Cluster 的 前 端 接口 ， 各 种 客户 端 工具 〈CLI sk UD 以 及 Kubernetes 其 他 组 件 可 
以 通过 它 管 理 Cluster 的 各 种 资源 。 

2. Scheduler ( kube-scheduler ) 


Scheduler 负责 决定 将 Pod 放 在 哪个 Node 上 运行 。Scheduler 在 调度 时 会 充分 考虑 
Cluster 的 拓扑 结构 ， 当 前 各 个 节点 的 负载 ， 以 及 应 用 对 高 可 用 、 性 能 、 数 据 亲 和 性 的 需求 。 


每 天 5 分 钟 玩 转 Kubernetes 


3. Controller Manager ( kube-controller-manager ) 


Controller Manager 负责 管理 Cluster 各 种 资源 ， 保 证 资源 处 于 预期 的 状态 。Controller 
Manager 由 多 种 controller 组 成 ， 包 括 replication controller、endpoints controller、namespace 
controller. serviceaccounts controller 等 。 

不 同 的 controller 管理 不 同 的 资源 。 例 如 ，replication controller 管理 Deployment. 
StatefulSet, DaemonSet 的 生命 周期 ，namespace controller 管理 Namespace 资源 。 

4. etcd 

etcd 负责 保存 Kubernetes Cluster 的 配置 信息 和 各 种 资源 的 状态 信息 。 当 数据 发 生变 化 
时 ，etcd 会 快速 地 通知 Kubernetes 相关 组 件 。 

5. Pod 网 络 

Pod 要 能 够 相互 通信 ，Kubernetes Cluster 必须 部 署 Pod 网 络 ，flannel 是 其 中 一 个 可 选 
方案 。 

以 上 是 Master. 上 运行 的 组 件 ， 下 面 我 们 接着 讨论 Node. 


4.2 Node 节点 


Node 是 Pod 运行 的 地 方 ，Kubernetes 支持 Docker, rkt 等 容器 Runtime. Node Lis 
行 的 Kubernetes 组 件 有 kubelet、kube-proxy 和 Pod 网 络 〈 例 如 flannel) ， 如 图 4-2 所 示 。 


$ flannel 


enp0s8 
192.168.56.106 (k8s-node1) 


图 4-2 





1. kubelet 
kubelet 是 Node 的 agent, ^4 Scheduler 确定 在 某 个 Node 上 运行 Pod 后 ,会 将 Pod 
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的 具体 配置 信息 (image、volume 等 ) 发 送 给 该 节点 的 kubelet，kubelet 根据 这 些 信 息 创 建 和 
运行 容器 ， 并 向 Master 报告 运行 状态 。 
2. kube-proxy 


service 在 逻辑 上 代表 了 后 端的 多 个 Pod， 外 界 通 过 service 访问 Pod. service 接收 到 的 
请 求 是 如 何 转发 到 Рой 的 呢 ? 这 就 是 kube-proxy 要 完成 的 工作 。 

每 个 Node 都 会 运行 kube-proxy 服务 , 它 负 责 将 访问 service 的 TCP/UPD 数据 流转 发 
到 后 端的 容器 。 如 果 有 多 个 副本 ，kube-proxy 会 实现 负载 均衡 。 


3. Pod 网 络 


Pod 要 能 够 相互 通信 ，Kubernetes Cluster 必须 部 署 Pod 网 络 ，flannel 是 其 中 一 个 可 选 
方案 。 


4.3 完整 的 架构 图 


结合 实验 环境 ， 我 们 得 到 了 如 图 4-3 所 示 的 架构 图 。 


enp0s8 
192.168.56.105 【k8s-master 


f flannel 


enp0s8 
192.168.56.106 (kBs-node1) 192.168.56.107 (k8s-node2) 





43 


21 


你 可 能 会 问 : 为 什么 kSs-master 上 也 有 kubelet 和 kube-proxy 18? 
这 是 因为 Master 上 也 可 以 运行 应 用 ， 即 Master 同时 也 是 一 个 Node。 
几乎 所 有 的 Kubernetes 组 件 本 身 也 运行 在 Pod 里 ， 执 行 如 下 命令 ， 结 果 如 图 4-4 所 示 。 


kubectl get pod --all-namespaces -o wide 























ubuntuekBs-mast 
ubuntuék8s-master:-$ kubectl get pod --all-namespaces -o wide 

NAMESPACE NAME READY STATUS RESTARTS АСЕ NODE 
Kube-system — etcd-k8s-master / Running 192. 05 k8s-moster 
kube-system — kube-apiserver-k8s-master Z: Running 192.168.56.105 k8s-moster 
Kube-system kube-controller-manager-k8s-master Running 192.168.56.105 — k8s-moster 
Kube-system ^ kube-dns-2425271678-123pv 7 Running 19.244.1.57 k8s-node1 
kube-system kube-flannel-ds-cqbpb / Running 192.168.56.106 К85-поде1 
Kube-system — kube-flannel-ds-vOp3x / Running 192.168.56.105 。 k8s-noster 
Kube-system — kube-flannel-ds-xk49w Running 192. 07  k8s-node2 
kube-system ^ kube-proxy-16mg9 "s Running 192.168.56.106 К85-поде1 
Kube-system — kube-proxy-wc4j / Running 192.168.56.105 — k8s-moster 
Kube-system — kube-proxy-xlSgd Running 192.168.56.107 ^ k8s-node2 
kube-system — kube-scheduler-k8s-master 7: Running 192.168.56.105 k8s-master 
ubuntu@k8s-master:~$ 





图 44 


Kubernetes 的 系统 组 件 都 被 放 到 kube-system namespace 中 。 这 里 有 一 个 kube-dns 组 件 ， 
它 为 Cluster 提供 DNS 服务 , 我 们 后 面 会 讨论 到 。kube-dns 是 在 执行 kubeadm init 时 (第 5 
步 ) 作为 附加 组 件 安装 的 。 

kubelet 是 唯一 没有 以 容器 形式 运行 的 Kubernetes 组 件 ， 它 在 Ubuntu 中 通过 Systemd 
服务 运行 ， 如 图 4-5 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ sudo systemctl status kubelet.service 
* kubelet.service - kubelet: The Kubernetes Node Agent 
Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) 
Drop-In: /etc/systemd/system/kubelet.service.d 
1—10-киреаат. conf 
Active: active (running) since Wed 2017-08-23 11:01:08 HKT; 1 day 5h ago 
Docs: http://kubernetes.io/docs/ 


Маїп PID: 3946 (kubelet) 
Tasks: 19 


Memory: 46.4M 
CPU: 20min 29.1495 
CGroup: /system.slice/kubelet.service 
F-3946 /usr/bin/kubelet --kubeconfig-/etc/kubernetes/kubelet.conf --require-kubeconfig-true 
1—3974 journalctl -k -f 





图 4-5 


用 例子 把 它们 串 起 来 


为 了 帮助 大 家 更 好 地 理解 Kubernetes 架构 ， 我 们 部 署 一 个 应 用 来 演示 各 个 组 件 之 间 是 如 
何 协 作 的 。 
执行 下 列 命 令 ， 结 果 如 图 4-6 所 示 。 
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kubectl run httpd-app --image-httpd --replicas-2 


ubuntuek8s-master:-$ 
ubuntuek8s-master:-$ kubectl run httpd-app --image-httpd --replicas-2 


deployment "httpd-app" created 
ubuntuek8s-master: -$ 





图 4-6 
等 待 一 段 时 间 ， 应 用 部 署 完成 ， 如 图 4-7 所 示 。 


$ kubectl get deployment 
DESIRED CURRENT UP-TO-DATE AVAILABLE АСЕ 
httpd-app 2 2 2 2 2т 
|ubuntuék8s master: -$ 


lubuntu&k8s-master:-$ kubectl get pod -o wide 

INAME READY STATUS RESTARTS АСЕ IP 
httpd-app-3211369089-9bgrz 1⁄4 Runing 0 2m 10.244.1.58 
httpd-opp-3211369089-gn6z5 1/1 Running 0 2m 19.244.2.39 
iubuntuék8s-master : -.$. 


4-7 


NODE 
k8s-nodel 
k8s-node2 





Kubernetes 部 署 了 deployment httpd-app， 有 两 个 副本 Pod， 分 别 运行 在 k8s-nodel 和 


k8s-node2. 
详细 讨论 整个 部 署 过 程 ， 如 图 4-8 所 示 。 


Ф © deployment 


kubectl API S 






f flannel 


@ 


D une] 





f flannel f flannel 


图 4-8 
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(D kubectl 发 送 部 署 请 求 到 API Server, 

@ API Server 通知 Controller Manager 创建 一 个 deployment 资源 。 

@ Scheduler 执行 调度 任务 ， 将 两 个 副本 Pod 分 发 到 kSs-nodel 和 К85-пойе2 。 

图 k8s-nodel 和 k8s-node2 上 的 kubectl 在 各 自 的 节点 上 创建 并 运行 Pod. 

补充 两 点 : 

CD 应 用 的 配置 和 当前 状态 信息 保存 在 etcd 中 , 执行 kubectl get рой 时 API Server 会 
从 etcd 中 读 取 这 些 数据 。 

(2) flannel 会 为 每 个 Pod 都 分 配 IP。 因 为 没有 创建 service， 所 以 目前 kube-proxy Ж 
没 参与 进来 。 





小 结 


本 章 我 们 学 习 了 Kubernetes 的 架构 ,讨论 了 Master 和 Node 是 哪个 运行 的 组 件 和 服务 ， 
并 通过 一 个 部 署 案例 加 深 了 对 架构 的 理解 。 


24 


第 5 = 


运行 应 用 


从 本 章 开 始 ， 我 们 将 通过 实践 深入 学 习 Kubernetes 的 各 种 特性 。 作 为 容器 编排 引擎 ， 最 
要 也 是 最 基本 的 功能 当然 是 运行 容器 化 应 用 ， 这 就 是 本 章 的 内 容 。 





Deployment 


前 面 我 们 已 经 了 解 到 ，Kubernetes 通过 各 种 Controller 来 管理 Pod 的 生命 周期 。 为 了 满 
足 不 同业 务 场景 ，Kubernetes 开发 了 Deployment, ReplicaSet, DaemonSet, StatefuleSet, Job 
等 多 种 Controller。 我 们 首先 学 习 最 常用 的 Deployment。 


5.1.1 运行 Deployment 
先 从 例子 开始 ， 运 行 一 个 Deployment: 
kubectl run nginx-deployment --image-nginx:1.7.9 --replicas-2 
上 面 的 命令 将 部 署 包 含 两 个 副本 的 Deployment nginx-deployment， 容 器 的 image 为 
nginx:1.7.9。 
下 面 详细 分 析 Kubernetes 都 做 了 些 什么 工作 ， 如 图 5-1 所 示 。 
ubuntuek8s-master :~$ 
ubuntuek8s-master:-$ kubectl run nginx-deployment --image-nginx:1.7.9 --replicas-2 


deployment "nginx-deployment" created 
ubuntuek8s-master :~$ 


ubuntuék8s-master:-$ kubectl get deployment nginx-deployment 

NAME DESIRED CURRENT  UP-TO-DATE AVAILABLE АСЕ 
nginx-deployment 2 2 2 2 23s 
ubuntuek8s-master :~$ 





Ё 5-1 
在 图 5-1 中 ， 通 过 kubectl get deployment. 命令 查看 nginx-deployment 的 状态 ， 输 出 显示 
两 个 副本 正常 运行 。 
接 下 来 我 们 用 kubectl describe deployment 了 解 更 详细 的 信息 ， 如 图 5-2 和 图 5-3 所 示 。 

















is-master:-$ kubectl describe deployment nginx-deployment 
nginx-deployment 
default 
Mon, 28 Aug 2017 10:28:32 +0800 
runenginx-deployment 
deployment.kubernetes.io/revisionsl 
runsnginx-deployment 
2 desired | 2 updated | 2 total | 2 available | 0 unavailable 
RollingUpdate 
° 
RollingUpdateStrategy: 1 max unavailable, 1 max surge 
Pod Template: 
Labels: runenginx-deployment 
Containers: 
nginx-deployment: 
Image: nginx:1.7.9 
Port: <попе> 
Environment: <none> 
Mounts: «none» 
Volumes: «none» 
Conditions: 
Type Status Reason 


Available MinimumReplicasAvailable 
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Message 





大 部 分 内 容 都 是 自 解释 的 ， 我 们 重点 看 图 5-3。 这 里 告诉 我 们 创建 了 一 个 ReplicaSet 
nginx-deployment-1260880958, Events 是 Deployment 的 日 志 ， 记 录 了 ReplicaSet 的 启动 过 
是 。 通 过 上 面 的 分 析 ， 也 验证 了 Deployment 通过 ReplicaSet 来 管理 Pod 的 事实 。 接 着 我 们 将 
注意 力 切换 到 nginx-deployment-1260880958， 执 行 kubectl describe replicaset， 如 图 5-4 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get replicaset 





МАМЕ DESIRED CURRENT READY AGE 
nginx-deployment-1260880958 2 2 z 3m 
ubuntu@k8s-master:~$ 
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两 个 副本 已 经 就 绪 ,， 用 kubectl describe replicaset 查看 详细 信息 ， 如 图 5-5 和 图 5-6 所 示 。 
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ubuntuêk8s-master:~$ 
ubuntuék8s-master:-$ kubectl describe replicaset nginx-deployment-1260880958 
Name: nginx-deployment-1260880958 
Namespace: default 
Selector: pod-template-hash-1260880958 ,run=nginx-depLoyment 
pod-template-hash=1260880958 
run=nginx-deployment 
deployment .kubernetes.io/desired-replicas=2 
deployment.kubernetes . io/max-replicas-3 
deployment.kubernetes .іо/геуіѕіоп=1 
Deployment/nginx-deployment 
2 current / 2 desired 
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed 
Pod Template: 
Labels: pod-template-hash-1260880958 
runenginx-deployment 
Containers: 
nginx-deployment: 
Image: nginx:1.7.9 
Port: «none» 
Environment: «none» 
Mounts: «none» 





5-5 


Reason Message 
SuccessfulCreate 
SuccessfulCreate 





图 5-6 


Controlled By 指明 此 ReplicaSet 是 由 Deployment nginx-deployment 创建 的 。 图 5-6 是 两 
个 副本 Pod 创建 的 日 志 。 接 着 我 们 来 看 Pod， 执 行 kubectl get pod， 如 图 5-7 所 示 。 


ubuntuék8s-master: -$ 
ubuntuek8s-master:-$ kubectl get pod 
МАМЕ READY STATUS RESTARTS AGE 


nginx-deployment-1260880958-kn8w3 1⁄1 Running 0 7m 
nginx-deployment-1260880958-rpjdc 1/1 Running 0 7т 
Ubuntuek8s-master:~: 





图 5-7 


两 个 副本 Pod 都 处 于 Running 状态 ， 然 后 用 kubectl describe pod 查看 更 详细 的 信息 ， 
如 图 5-8 和 图 5-9 所 示 。 
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mz е 
lubuntu&k8s-master:-$ kubectl describe pod nginx-deployment-1260880958-kn8w3 

nginx-deployment-1260880958-kn8w3 

defoult 

k8s-node1/192.168.56.106 

Mon, 28 Aug 2017 10:28:32 +0800 

pod-template-hash=1260880958 

run=nginx-deployment 

kubernetes .io/created-by={"kind":"SerializedReference", "apiVersio! 


Running 
10.244.1.69 
ReplicoSet/nginx-deployment-1260880958 
260880958 ) 


Containers 
nginx-deployment: 
Contoiner ID: docker://2653d5b30075c16632ac2e3fc0fd5411b194953547c0c5035913334b7e0d0b 
nginx:1.7.9 
docker-pulloble://nginx&sha256: e3456c8510152494c3e4f 5f cc26f2402060bac0c9d79. 
«none» 
Running 
Storted: Mon, 28 Aug 2017 10:28:33 +0800 
Reody: True 
Restart Coun ° 
Environment: <none> 
Mounts: 
/var/run/secrets/kubernetes.io/serviceaccount from defoult-token-slv6h Cro) 
Conditions: 
Type Status 
Initialized True 
Ready True 
PodScheduled True 
Volumes: 
default-token-siv6h: 
Type: Secret (a volume populated by a Secret) 
SecretNome: default-token-siv6h 
Optional: false 
RoS Class: BestEffort 
Node 


Reason 

Scheduled Successfully assigned nginx-deployment-1260880958-kn8w3 to k 
SuccessfulMountVolume ^ MountVolume.SetUp succeeded for volume "default-token-s1v6h"| 
Pulled Contoiner image "nginx:1.7.9" already present on machine 


Creoted Created container 
Started Started container 


Eg 5-9 

















Controlled By 指明 此 Pod 是 由 ReplicaSet nginx-deployment-1260880958 创建 的 。Events 
记录 了 Pod 的 启动 过 程 。 如 果 操作 失败 〈 比 如 image 不 存在 ) ， 也 能 在 这 里 查 到 原因 。 
总 结 一 下 这 个 过 程 中 ， 如 图 5-10 所 示 。 


(1) 用 户 通 过 kubectl 创建 Deployment。 
(2) Deployment 创建 ReplicaSet。 
(3) ReplicaSet 创建 Pod。 
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Ө nginx-deployment 
© nginx-deployment-1260880958 
a io" 


mgimdeployment-260880958-kn8w3 — — ngimv-deployment-1260880958-rpjdc 


BI 5-10 
从 图 5-10 也 可 以 看 出 ， 对 象 的 命名 方式 是 “ 子 对 象 的 名 字 = 父 对 象 名 字 + 随机 字符 串 


512 命令 vs 配置 文件 
Kubernetes 支持 两 种 创建 资源 的 方式 : 


(1) 用 kubectl 命令 直接 创建 ， 比 如 “kubectl гип nginx-deployment --image=nginx:1.7.9 
--replicas=2”， 在 命令 行 中 通过 参数 指定 资源 的 属性 。 

(2) 通过 配置 文件 和 kubectl apply 创建 。 要 完成 前 面 同样 的 工作 ， 可 执行 命令 “kubectl 
apply -fnginx.yml”，nginx.yml 的 内 容 如 图 5-11 所 示 。 


apiVersion: extensions/vlbetal 
kind: Deployment 
metadata 
name: nginx-deployment 
spec 
гер11са$ 
template 

metadata 

labels 

app: web_server 
spec 
containers 


name: nginx 
image: nginx:1.7.9 





图 5-11 
资源 的 属性 写 在 配置 文件 中 ， 文 件 格式 为 YAML. 
下 面 对 这 两 种 方式 进行 比较 。 

(1) 基于 命令 的 方式 : 


e AŽ, ER, RR, LFR 
e 适合 临时 测试 或 实验 。 
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(2) 基于 配置 文件 的 方式 : 

配置 文件 描述 了 What， 即 应 用 最 终 要 达到 的 状态 。 
配置 文件 提供 了 创建 资源 的 模板 ， 能 够 重复 部 署 。 
可 以 像 管理 代码 一 样 管理 部 署 。 

适合 正式 的 、 跨 环境 的 、 规 模 化 部 署 。 

这 种 方式 要 求 熟悉 配置 文件 的 语法 ， 有 一 定 难 度 。 


后 面 我 们 都 将 采用 配置 文件 的 方式 ， 大 家 需要 尽快 熟悉 和 掌握 。 
kubectl apply 不 但 能 够 创建 Kubernetes 资源 ， 也 能 对 资源 进行 更 新 ， 非 常 方便 。 不 过 





Kubernets 还 提供 了 几 个 类 似 的 命令 ， 例 如 kubectl create, kubectl replace、kubectl edit 和 
kubectl patch 。 


为 避免 造成 不 必要 的 困扰 ， 我 们 会 尽量 只 使 用 kubectl apply, 此 命令 已 经 能 够 应 对 百 分 


之 九 十 多 的 场景 ， 事 半 功 倍 。 





5.1.3 Deployment 配置 文件 简介 


T, 


既然 要 用 YAML 配置 文件 部 署 应 用 , 现在 就 很 有 必要 了 解 一 下 Deployment 的 配置 格式 
其 他 Controller (比如 DaemonSet) 非常 类 似 。 
以 nginx-deployment 为 例 ， 配 置 文 件 如 图 5-12 所 示 。 


apiVersion: extensions/vibetal 
kind: Deployment 
пе: lata 

e: nginx-deployment 


spe 
replicas 
template 
metadata 

labels 

app: web_server 
spec 

containers 

e: nginx 
image: пдїпх:1.7.9 





图 5-12 


@) apiVersion 是 当前 配置 格式 的 版 本 。 

@) kind 是 要 创建 的 资源 类 型 ， 这 里 是 Deployment。 

®© metadata 是 该 资源 的 元 数据 ，name 是 必需 的 元 数据 项 。 

@ spec 部 分 是 该 Deployment 的 规格 说 明 。 

©) replicas 指明 副本 数量 ， 默 认为 1。 

template 定义 Pod 的 模板 ， 这 是 配置 文件 的 重要 部 分 。 

C) metadata 定义 Pod 的 元 数据 ， 至 少 要 定义 一 个 label. label 的 key 和 value 可 以 任 
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(& spec 描述 Pod 的 规格 ， 此 部 分 定义 Pod 中 每 一 个 容器 的 属性 ，name 和 image 是 必需 的 。 


此 nginx.yml 是 一 个 最 简单 的 Deployment 配置 文件 ， 后 面 我 们 学 习 Kubernetes 各 项 功 
能 时 会 逐步 丰富 这 个 文件 。 
执行 kubectl apply -fnginx.yml， 如 图 5-13 所 示 。 


ubuntuek8s-master :~$ 
ubuntuék8s-master:-$ kubectl apply -f nginx.yml 


deployment "nginx-deployment" created 
ubuntuek8s-master : -$ 





图 5-13 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 2 2 2 E 17s 
lubuntuek8s -mastei 
ubuntu&k8s-master:-$ kubectl get replicaset 
NAME DESIRED CURRENT READY AGE 
nginx-deployment-2721169382 2 2 2 29s 

$ 

kubectl get pod -o wide 

READY STATUS RESTARTS AGE NODE 

nginx-deployment-2721169382-bl3cn 1/1 Running 0 415 .244.2. k8s-node2 
nginx-deployment-2721169382-x6f3z 1⁄1 Running 0 415 244.1. k8s-nodel 
ubuntuek8s-master:-4 





图 5-14 


Deployment、ReplicaSet、Pod 都 已 经 就 绪 。 如 果 要 删除 这 些 资源 ， 执 行 kubectl delete 
deployment nginx-deployment 或 者 kubectl delete -fnginx.yml， 如 图 5-15 所 示 。 
ubuntuek8s-master:-$ 
ubuntuék8s-master:-$ kubectl delete -f nginx.yml 


deployment "nginx-deployment" deleted 
ubuntuek8s-master: ~$ 





图 5-15 


5.1.4 伸缩 


伸缩 是 指 在 线 增 加 或 减少 Pod 的 副本 数 。 
Deployment nginx-deployment 初始 是 两 个 副本 ， 如 图 5-16 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" created 
ubuntuek8s -master:-$ 

ubuntuek8s-master:-$ kubectl get pod -o wide 


МАМЕ READY STATUS RESTARTS AGE NODE 


nginx-deployment-2721169382-1gzzf 1⁄1 Running 0 8s 244.2.91 k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running @ 85 244.1.81 k8s-node1 
ubuntuek8s-master:--$ 





图 5-16 


k8s-nodel 和 k8s-node2 上 各 跑 了 一 个 副本 。 现 在 修改 nginx.yml 文件 ， 将 副本 改 成 5 个 ， 
如 图 5-17 所 示 。 
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apiVersion: extensions/v1betal 
kind: Deployment 
imetadata 
name: nginx-deployment 
spec 


licas 


template 


metadata 
labels 
app: web_server 
spec 
containers 
name: nginx 
image: nginx:1.7.9 





图 5-17 


再 次 执行 kubectl apply， 如 图 5-18 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 

deployment "nginx-deployment" configured 

lubuntuek8s -master : —- 

ubuntuek8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS NODE 
nginx-deployment-2721169382-gbjc2 1⁄1 Running К k8s-node2 
nginx-deployment-2721169382-1gzzf 1/1 Running : Ў k8s-node2 
nginx-deployment-2721169382-mbrln 1/1 Running К : k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running Š 5 k8s-node1 
nginx-deployment-2721169382-s6hlx 1/1 Running 2 s k8s-nodel 
ubuntuek8s master :~$ 





图 5-18 


三 个 新 副本 被 创建 并 调度 到 kSs-nodel 和 k8s-node2 上 。 
出 于 安全 考虑 ， 默 认 配 置 下 Kubernetes 不 会 将 Pod 调度 到 Master 节点 。 如 果 希 望 将 
k8s-master 也 当 作 Node 使 用 ， 可 以 执行 如 下 命令 : 


kubectl taint node k8s-master node-role.kubernetes.io/master- 
如 果 要 恢复 Master Only 状态 ， 执 行 如 下 命令 : 
kubectl taint node k8s-master node-role.kubernetes.io/master-"":NoSchedule 


接 下 来 修改 配置 文件 ， 将 副本 数 减少 为 3 个 ， 重 新 执行 kubectl apply, 1 5-19 所 示 。 
ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" configured 
ubuntuék8s-mastei 
ubuntuék8s-master:-$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE NODE 
nginx-deployment-2721169382-gbjc2 1/1 Running 14m .244.2. k8s-node2 
nginx-deployment-2721169382-lgzzf 1/1 Running 18m .244.2. k8s-node2 
nginx-deployment-2721169382-mbrln 0/1 Terminating 14m k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running 18т 10.244.1.81 К85-пойе1 
ubuntuek8s-master:-$ 
Ubuntuek8s-mastei $ kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE NODE 
nginx-deployment-2721169382-gbjc2 1/1 Running 14m A i k8s-node2 
nginx-deployment-2721169382-lgzzf 1/1 Running 18m У e k8s-node2 
nginx-deployment-2721169382-pt53w 1⁄1 Running 18m .244.1. k8s-node1 
ubuntu@k8s-master:~$ 











图 5-19 


可 以 看 到 两 个 副本 被 删除 ， 最 终 保留 了 3 个 副本 。 
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5.1.5 Failover 


下 面 我 们 模拟 kSs-node2 故障 ， 关 闭 该 


节点 ， 如 图 5-20 所 示 。 


rootek8s-node2 : halt -h 


Connection to 192.168.56.107 closed by remote host. 


Connection to 192.168.56.107 closed. 





图 5-20 


等 待 一 段 时 间 ,， Kubernetes 会 检查 到 k8s-node2 不 可 用 , 将 k8s-node2 上 的 Pod 标记 为 


Unknown 状态 ， 并 在 k8s-nodel 


[ubuntuek8s-master:-$ 
ubuntuek8s-master: 
NAME STATUS 
k8s-master Ready 


AGE 
6d 
54 


$ kubectl get node 


VERSION 
v1.7.4 
v1.7.4 


v1.7.4 
-master 
kubectl get pod -o wide 
READY 
1/1 
1/1 
1/1 
1/1 
1/1 


ubuntu@k8s. 


nginx-deployment-2721169382-gbjc2 
nginx-deployment-2721169382-lgzzf 
nginx-deployment-2721169382-p4mhr 
nginx-deployment-2721169382-pt53w 
nginx-deployment-2721169382-x8rtb 
ubuntu@k8s-master:~$ 


STATUS 
Unknown ° 
Unknown 0 
Running 
Running 
Running 


RESTARTS 


图 5-21 


k8s-node2 恢复 后 ，Unknown 的 Pod 
回 k8s-node2， 如 图 5-22 所 示 。 


ubuntu@k8s-master:~$ 
ubuntuék8s-master:-$ kubectl get node 
NAME STATUS VERSION 
k8s-master Ready v1.7.4 
k8s-nodel Ready v1.7.4 
k8s-node2 ^ Ready v1.7.4 
ubuntuék8s-master :~$ 


ubuntuék8s-master:-$ kubectl get pod -o wide 


会 被 删除 ， 不 过 已 经 


NODE 
k8s-node2 
du node? 


.244.2.93 
2255 25 91 


E 1. 81 
.244.1.83 


k8s-nodel 
k8s-node1 





运行 的 Pod 不 会 


上 新 创建 两 个 Pod， 维 持 总 副本 数 为 3， 如 图 5-21 所 示 。 


重新 调度 


NAME 
nginx-deployment-2721169382-p4mhr 
nginx-deployment-2721169382-ptS3w 
nginx-deployment-2721169382-x8rtb 
ubuntuêk8s-master :~$ 


删除 nginx-deployment， 如 图 


ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ 
"nginx-de 


deployment 





READY 
1/1 
1/1 
1/1 


STATUS 

Running 
Running 
Running 


RESTARTS AGE 
12т 
39m 


12т 


IP 

10.244.1.87 
10.244.1.85 
10.244.1.88 


图 5-22 


5-23 所 示 。 


kubectl delete deployment 
ployment" deleted 


nginx-deployment 





ubuntuék8s-master:-$ 


图 5-23 


5.1.6 用 label 控制 Pod 的 位 置 
默认 配置 下 ，Scheduler 


会 将 Pod 调度 到 所 有 可 用 的 Node。 不 过 有 些 


情况 我 们 希望 将 
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Pod 部 署 到 指定 的 Node， 比 如 将 有 大 量 磁盘 IO 的 Pod 部 署 到 配置 了 SSD 的 Node; 或 
者 Pod 需要 GPU， 需 要 运行 在 配置 了 GPU 的 节点 上 。 

Kubernetes 是 通过 label 来 实现 这 个 功能 的 。 

label 是 key-value 对 ， 各 种 资源 都 可 以 设置 label， 灵 活 添加 各 种 自 定义 属性 。 比 如 执行 
如 下 命令 标注 k8s-nodel 是 配置 了 SSD 的 节点 。 








kubectl label node k8s-nodel disktype=ssd 


然后 通过 kubectl get node --show-labels 查看 节点 的 label， 如 图 5-24 所 示 。 


ss-master:~ 

ubuntuék8s-master:-$ kubectl label node k8s-nodel disktype=ssd 
node "k8s-nodel" labeled 

ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl get node --show-labels 

NAME STATUS AGE VERSION LABELS 





k8s-master Ready v1.7.4 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hos; 
k8s-nodel Ready v1.7.4 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux Gisktype=ssd) ube! 
k8s-node2 Ready v1.7.4 beta.kubernetes . io/arch-amd64 , beta. kubernetes.io/os-linux, 
ubuntuek8s-master: ~$ 


图 5-24 


disktype-ssd 已 经 成 功 添加 到 kSs-nodel, FR f disktype, Node 还 有 几 个 Kubernetes Н 
己 维护 的 label。 

有 了 disktype 这 个 自 定义 label， 接 下 来 就 可 以 指定 将 Pod 部 署 到 kSs-nodel. 44H 
nginx.yml， 如 图 5-25 所 示 。 


apiVersion: apps/vlbetal 
kind: Deployment 
metadata 

name: nginx-deployment 
spec 

replicas 

template 

metadata 


labels 
app: web_server 
spec 
containers 
name: nginx 


image: nginx:1.7.9 
nodeSelector 
disktype: ssd 





图 5-25 


在 Pod 模板 的 spec 里 通过 nodeSelector 指定 将 此 Pod 部 署 到 具有 label disktype=ssd 
的 Node 上 。 
部 署 Deployment 并 查看 Pod 的 运行 节点 ， 如 图 5-26 所 示 。 
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ubuntuekBs-master:-$ 

ubuntuék8s-master:-$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" created 
ubuntuek8s-master:—$ 

ubuntu@k8s-moster:-$ kubectl get pod -o wide 

NAME READY STATUS 
nginx-deployment-204403116-1kk23 1⁄1 Running 


nginx-deployment-204403116-gcnkz 1⁄1 Running 
nginx-deployment-204403116-kmbwr — 1/ Running 
nginx-deployment-204403116-kzpnf —1/ Running 
nginx-deployment-204403116-vbz47 1⁄ Running 
nginx-deployment-204403116-vvh54 1/ Running 
ubuntuêk8s-master :~$ 





图 5-26 


全 部 6 个 副本 都 运行 在 kSs-nodel 上 ， 符 合 我 们 的 预期 。 
要 删除 label disktype， 执 行 如 下 命令 : 


kubectl label node k8s-nodel disktype- 


- 即 删除 ， 如 图 5-27 所 示 。 


label node k8s-nodel disktype. 


tl get node --show-lobels 
LABELS. 
beta. kubernetes. io/arch-omd64 , beta. kubernetes. io, 1 master ,node-role.kubernetes 
kubernetes. io/arch-ond64 beta. kubernetes. io; kubernete: 
kubernetes. io/arch-omd64 beta. kubernetes. io; kubernete: 





图 5-27 
不 过 此 时 Pod 并 不 会 


ubuntu@k8s -master:-$ 

ubuntuek8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS NODE 
nginx-deployment-204403116-1kk23 1/1 Running k8s-node 
nginx-deployment-204403116-gcnkz 1⁄1 Running k8s-node 
nginx-deployment-204403116-kmbwr 1⁄1 Running .244.1. k8s 
Inginx-deployment-204403116-kzpnf 1⁄1 Running 6 .244.1. k8: 
nginx-deployment-204403116-vbz47 1⁄1 Running .244.1. k8: 
nginx-deployment-204403116-vvh54 1/1 Running 

ubuntu@k8s-master:~$ 





所 部 署 ， 依 然 在 k8s-nodel 上 运行 ， 如 图 5-28 所 示 。 





图 5-28 


除非 在 nginx.yml 中 删除 nodeSelector 设置 ， 然 后 通过 kubectl apply 重新 部 署 ， 如 图 5-29 
所 示 。 


ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 

deployment "nginx-deployment" configured 

lubuntuek8s-master:- 

lubuntuk8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS IP NODE 
nginx-deployment-204403116-1kk23 9/1 Terminating <none> k8s-node1 
nginx-deployment-204403116-kmbwr 1⁄ Terminating n 1@.244.1. k8s-node1 
nginx-deployment-204403116-kzpnf ⁄ Terminating <none> k8s-node1 
nginx-deployment-204403116-vbz47 0/ Terminating 7 <none> k8s-nodel 
nginx-deployment-204403116-vvh54 Terminating «none» k8s-node1 
nginx-deployment-2721169382-56mhh 1/ Running 10.244.2. k8s-node2 
nginx-deployment-2721169382-bfürd 1/ Running 10.244. k8s-node2 
Inginx-deployment-2721169382-cnh8b Running 10.244.2. k8s-node2 
Inginx-deployment-2721169382-lqhn6 Running 10.244. k8s-node2 
nginx-deployment-2721169382-q61jr 1/ Running 10.244.1. k8s-nodel 
nginx-deployment-2721169382-r983l 1/ Running 10.244. k8s-node2 
ubuntuék8s-master:-$ 





图 5-29 


Kubernetes 会 删除 之 前 的 Pod 并 调度 和 运行 新 的 Pod. 
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DaemonSet 


Deployment 部 署 的 副本 Pod 会 分 布 在 各 个 Node 上 ， Node 都 可 能 运行 好 几 个 副 
Ж. DaemonSet 的 不 同 之 处 在 于 : 每 个 Node 上 最 多 只 能 运行 一 个 副本 。 
DaemonSet 的 典型 应 用 场景 有 : 


(1) 在 集群 的 每 个 节点 上 运行 存储 Daemon， 比 如 glusterd 或 ceph。 
(2) 在 每 个 节点 上 运行 日 志 收集 Daemon， 比 如 flunentd 或 logstash 。 
(3) 在 每 个 节点 上 运行 监控 Daemon， 比 如 Prometheus Node Exporter 或 collectd。 


其 实 Kubernetes 自己 就 在 用 DaemonSet 运行 系统 组 件 。 执 行 如 下 命令 , 如 图 5-30 所 示 。 


kubectl get daemonset --namespace-kube-system 











ubuntu@k8s-master:~$ 

:~$ kubectl get daemonset --namespace-kube-system 

DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR 
kube-flannel-ds 3 3 beta.kubernetes.io/arch=a 
kube-proxy 3 3 3 <none> 
ubuntuek8s-master:~ 





图 5-30 


DaemonSet kube-flannel-ds 和 kube-proxy 分 别 负责 在 每 个 节点 上 运行 flannel 和 
kube-proxy 组 件 ， 如 图 5-31 所 示 。 


ubuntuek8s-master:-$ 
ubuntuekBs-master:-$ kubectl get pod --namespoceskube-system -o wide 
НАМЕ READY STATUS — RESTARTS IP NODE 
etcd-k8s-master 1/1 Running 1 192.168.56.105 — k8s-master 
kube-apiserver-k8s-master 1/1 Running 1 192.168.56.105 — k8s-master 
kube-controller-manager-k8s-master 1⁄1 Running 1 192.168.56.105 。 k8s-master 
kube-dns-2425271678-51xc4 3/; Running 6 10.244.1.89 k8s-node1 
ube- flannel -ds-cqbpb Running T kšs-nodel 
flannel-ds-vOp3x / Running 3 2.168.56. k8s-master 
-flannel -ds-xk49w ⁄ Running 1 k8s-node2 
-proxy-16mg9 ⁄ Running 3 k8s-node1 
-proxy-wc4j9 / Running 1 kBs-master 
-proxy-x15gd @ Running 4 k8s-node2 


ubuntuekBs- master: 





图 5-31 


因为 flannel 和 kube-proxy 属于 系统 组 件 ， 需 要 在 命令 行 中 通过 --namespace=kube-system 
指定 namespace kube-system。 若 不 指定 ， 则 只 返回 默认 namespace default 中 的 资源 。 





5.2.1 kube-flannel-ds 


下 面 我 们 通过 分 析 kube-flannel-ds 来 学 习 DaemonSet。 
还 记得 之 前 是 如 何 部 署 flannel 网 络 的 吗 ? 我 们 执行 了 如 下 命令 : 


kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/ 
Documentation/kube-flannel.yml 
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flannel 的 DaemonSet 就 定义 在 kube-flannel.yml 中 ， 如 图 5-32 所 示 。 


lapiVersion: extensions/vibetal 
kind: DaemonSet 
metadata 
name: kube-flannel-ds 
namespace: kube-system 
labels 
tier: node 
app: flannel 
spec 
template 
metadata 
labels 
tier: node 
app: flannel 
spec 
hostNetwork 
nodeSelector 
beta.kubernetes.io/arch: amd64 
containers 
name: kube-flannel 
image: quay.io/coreos/flannel:v0.8.0-amd64 
command , 
- name: install-cni 
image: quoy.io/coreos/flonnel:v0.8.0-amd64 
command А Я 





І 5-32 


注意 : 配置 文件 的 完整 内 容 要 更 复杂 一 些 ， 为 了 更 好 地 学 习 DaemonSet， 这 里 只 保留 了 
要 的 内 容 。 


@ DaemonSet 配置 文件 的 语法 和 结构 与 Deployment 几乎 完全 一 样 ， 只 是 将 kind Wy 


Daemonset。 


@ hostName 指定 Pod 直接 使 用 的 是 Node 网 络 ， 相 当 于 docker run --network=host。 考 


虑 到 flannel 需要 为 集群 提供 网 络 连接 ， 这 个 要 求 是 合理 的 。 


@ containers 定义 了 运行 flannel 服务 的 两 个 容器 。 


面 我 们 再 来 分 析 另 一 个 DaemonSet: kube-proxy。 


5.2.2 kube-proxy 




















无 法 拿 到 kube-proxy 的 YAML 文件 ， 只 能 运行 如 下 命令 查看 配置 : 
kubectl edit daemonset kube-proxy --namespace-kube-system 


结果 如 图 5-33 所 示 。 
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apiVersion: extensions/vibetol 
kind: DaemonSet (1 
metadata: 
labels: 
k8s-app: kube-proxy 
name: kube-proxy 
namespace: kube-system 
spec: 
selector: 
matchLabels 
k8s-app: kube-proxy 
template: 
metadata: 
labels: 
k8s-app: kube-proxy 
spec: 
containers 
command : 
- /usr/local/bin/kube-proxy 
- --kubeconfig=/var/lib/kube-proxy/kubeconfig. conf 
- --cluster-cidr-10.244.0.0/16 
image: gcr.io/google. containers/kube-proxy-amd64:v1.7.4 
name: kube-proxy 
status 
currentNumberScheduled 
desiredNumberScheduled 
numberAvailable: 
numberMisscheduled 
numberReody: 
observedGeneration 
updatedNumberScheduled 





图 5-33 
同样 为 了 便于 理解 ， 这 里 只 保留 了 最 重要 的 信息 。 
@ kind: DaemonSet 指定 这 是 一 个 DaemonSet 类 型 的 资源 。 
(©) containers 定义 了 kube-proxy 的 容器 。 
@ status 是 当前 DaemonSet 的 运行 时 状态 ， 这 个 部 分 是 kubectl edit 特有 的 。 其 实 
Kubernetes 集群 中 每 个 当前 运行 的 资源 都 可 以 通过 kubectl edit 查看 其 配置 和 运行 状态 , 比如 
kubectl edit deployment nginx-deployment。 








5.2.3 运行 自己 的 DaemonSet 


本 小 节 以 Prometheus Node Exporter 为 例 演 示 用 户 如 何 运 行 自己 的 DaemonSet。 

Prometheus 是 流行 的 系统 监控 方案 , Node Exporter 是 Prometheus 的 agent， 以 Daemon 
的 形式 运行 在 每 个 被 监控 节点 上 。 

如 果 是 直接 在 Docker 中 运行 Node Exporter 容器 ， 命 令 为 : 











docker run -d \ 
-v "/proc:/host/proc" V 
-v "/sys:/host/sys" \ 
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=ч "/;:/rootfs" N 

--net-host \ 

prom/node-exporter V 

--path.procfs /host/proc \ 

--path.sysfs /host/sys \ 

--collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host| 
etc) ($| /)" 


将 其 转换 为 DaemonSet 的 YAML 配置 文件 node exporter.yml, Ш 5-34 所 示 。 


apiVersion: ехёепѕ1опѕ/у1беёа1 
kind: DaemonSet 
etadata: 
name: node-exporter-daemonset 
Брес 
template: 
metadata 

labels 
app: prometheus 

spec: 

hostNetwork 

containers: 

- name: node-exporter 
image: prom/node-exporter 
imagePullPolicy: IfNotPresent 
command 2 

/bin/node exporter 
--path.procfs 
/host/proc 
--path.sysfs 


/host/sys 
--collector.filesystem.ignored-mount-points 
^/CsyslprocIdevIhostletc)($1/) 
volumeMounts 3 


- name: proc 
mountPath: /host/proc 
- name: sys 
mountPath: /host/sys 
name: root 
mountPath: /rootfs 
volumes: 
- name: proc 
hostPath: 
path: /proc 
- name: sys 
hostPath: 
path: /sys 
- name: root 
hostPath: 
path: / 





图 5-34 


© 直接 使 用 Host 的 网 络 。 
@ 设置 容器 启动 命令 。 
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© 通过 Volume 将 Host 路 径 /proc. /sys 和 / 映射 到 容器 中 。 我 们 将 在 后 面 详细 讨论 


Volume。 


执行 kubectl apply -fnode_exporteryml， 如 图 5-35 所 示 。 


ubuntu&k8s master :-$ 

lubuntuék8s-master:-$ kubectl apply -f node.exporter.yml 
|daemonset "node-exporter-daemonset" created 

ubuntu@k8s -master:~$ 


ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
node-exporter-daemonset-bzwgx 1/1 Running 0 65 192.168.56.107 К85-пойе2 
node-exporter-daemonset-kvmkr 1/1 Running 0 6s 192.168.56.106 К85-пойе1 
ubuntu&k8s-naster:-$ 





图 5-35 


DaemonSet node-exporter-daemonset 部 署 成 功 ，k8s-nodel 和 k8s-node2 上 分 别 运行 了 
个 node exporter Pod. 


Job 


容器 按照 持续 运行 的 时 间 可 分 为 两 类 : 服务 类 容器 和 工作 类 容器 。 
服务 类 容器 通常 持续 提供 服务 ， 需 要 一 直 运行 ， 比 如 HTTP Server. Daemon 等 。 工 作 类 
容器 则 是 一 次 性 任务 ， 比 如 批 处 理 程序 ， 完 成 后 容器 就 退出 。 
Kubernetes 的 Deployment, ReplicaSet 和 DaemonSet 都 用 于 管理 服务 类 容器 ; 对 于 工作 
类 容器 ， 我 们 使 用 Job。 
先 看 一 个 简单 的 Job 配置 文件 myjob.yml， 如 图 5-36 所 示 。 
apiVersion: batch/v1 
kind: Job 
metadata: 
name: myjob 
spec 


template: 
metadata: 


name: myjob 
spec: 
containers 
- name: hello 
image: busybox 
command: [ P 
restartPolicy: Never 





图 5-36 
(D batch/vl 是 当前 Job 的 apiVersion. 
Q) 指明 当前 资源 的 类 型 为 Job。 
@) restartPolicy 指定 什么 情况 下 需要 








。 对 于 Job， 只 能 设置 为 Never 或 者 
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OnFailure。 对 于 其 他 controller (比如 Deployment) ， 可 以 设置 为 Always 。 





通过 kubectl apply -f myjob.yml 启动 Job， 如 图 5-37 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 


job "myjob" created 
ubuntu@k8s-master:~$ 





图 5-37 


通过 kubectl get job 查看 Job 的 状态 ， 如 图 5-38 所 示 。 


ubuntu@k8s-master:~$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob + 1 125 
ubuntu@k8s-master : ~$ 





图 5-38 


DESIRED 和 SUCCESSFUL 都 为 1， 表 示 按 照 预 期 启动 了 一 个 Рой, 
行 。 通 过 kubectl get pod 查看 Pod 的 状态 ， 如 图 5-39 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod 

No resources found, use --show-all to see completed objects. 
ubuntuek8s-master:~$ 

ubuntuek8s-master:-$ kubectl get pod --show-all 

NAME READY STATUS RESTARTS AGE 
myjob-nfkxk 0/1 Completed 0 2m 
ubuntuek8s master: $ 





图 5-39 


并 且 已 经 成 功 执 


因为 Pod 执行 完毕 后 容器 已 经 退出 ， 需 要 用 --show-all 才能 查看 Completed 状态 的 Podo 


通过 kubectl logs 可 以 查看 Pod 的 标准 输出 ， 如 图 5-40 所 示 。 


ubuntuêk8s-master : ~$ 
ubuntuek8s-master:~$ kubectl logs myjob-nfkxk 


hello k8s job! 
ubuntuék8s-master:-$ 





图 5-40 


5.3.1 Pod 失败 的 情况 


以 上 是 Pod 成 功 执行 的 情况 ， 如 果 Pod 失败 了 会 怎么 样 呢 ? 
我 们 做 个 试验 ， 修 改 myjob.yml， 故 意 引 入 一 个 错误 ， 如 图 5-41 所 示 。 
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apiVersion: batch/vi 


name: myjob 
spec 
template 
metadata 
name: myjob 
spec 
containers 
- nome: hello 
bu: 





图 5-41 


先 删除 之 前 的 Job， 如 图 5-42 所 示 。 


ubuntuek8s-master:~$ 
ubuntuék8s-master:-$ kubectl delete -f myjob.yml 
job "myjob" deleted 
ubuntuek8s-master: $ 





5-42 
运行 新 的 Job 并 查看 状态 ， 如 图 5-43 所 示 。 


ubuntuek8s-master 

ubuntuek8s-master:-$ kubectl apply -f myjob.yml 
job "myjob" created 

ubuntuék8s-master:-$ 

ubuntuek8s-master kubectl get job 

NAME DESIRED SUCCESSFUL ] AGE 

myjob 0 75 
ubuntuek8s-master 





图 5-43 


当前 SUCCESSFUL 的 Pod 数量 为 0， 查 看 Pod 的 状态 ， 如 图 5-44 所 示 。 


:~$ kubectl get pod --show-all 
STATUS RESTARTS AGE 
ContainerCannotRun 
ContainerCannotRun 
ContainerCannotRun 
ContainerCannotRun 
ContainerCannotRun 
ContainerCreating 





[ubuntuek8s-master: 


图 5-44 


可 以 看 到 有 多 个 Pod， 状 态 均 不 正常 。 通 过 kubectl describe pod. 查看 某 个 Pod 的 启动 日 
志 ， 如 图 5-45 所 示 。 


Sub0bjectpoth Reoson Меззоде 


Scheduted Successfully assigned myjob-0x0z0 to k8s-node2 
Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume “default-token-k87vh" 


-Containers(hello) Normal Pulling pulling image "busybox" 
Normal Pulled Successfully pulled imoge "busybox" 
Normol Creoted Creoted contoiner z = ET 
-containers(hello) Warning Failed Error: failed to start container "hello": (execut not found in SPATH 
Warning FailedSync Error syncing pod Е €—— 





图 5-45 
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日 志 显 示 没 有 可 执行 程序 ， 符 合 我 们 的 预期 。 

下 面 解释 一 个 现象 : 为 什么 kubectl get pod 会 看 到 这 么 多 个 失败 的 Pod? 

原因 是 : 当 第 一 个 Pod 启动 时 ， 容 器 失败 退出 ， 根 据 restartPolicy: Never， 此 失败 容器 
不 会 被 重启 ， 但 Job DESIRED 的 Pod 是 1， 目 前 SUCCESSFUL 为 0， 不 满足 ， 所 以 Job 
controller 会 启动 新 的 Pod, 直到 SUCCESSFUL 为 1。 对 于 我 们 这 个 例子 , SUCCESSFUL Ж 
远 也 到 不 了 1， 所 以 Job controller 会 一 直 创 建新 的 Pod。 为 了 终止 这 个 行为 ， 只 能 删除 Job, 
如 图 5-46 所 示 。 











ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete -f myjob.yml 


job "myjob" deleted 
ubuntuek8s-master:-$ 





图 5-46 


如 果 将 restartPolicy 设置 为 OnFailure 会 怎么 样 ? 下 面 我 们 实践 一 下 ， 修 改 myjob.yml 
JAZ WEI 5-47 所 示 。 


ubuntuék8s-master:-$ 

ubuntuek8s-master:-$ kubectl apply -f myjob.yml 
job "myjob" created 

ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get job 

NAME DESIRED SUCCESSFUL AGE 

myjob it 0 5s 
ubuntuek8s-master:-$ 











图 5-47 
Job 的 SUCCESSFUL Pod 数量 还 是 0， 再 看 看 Pod 的 情况 ， 如 图 5-48 所 示 。 


ubuntuêk8s-master :~$ 
ubuntuék8s-master:-$ kubectl get pod --show-all 


INAME READY STATUS RESTARTS АбЕ 
myjob-831x0 0/1 CrashLoopBackoff (3 lm 


ubuntu@k8s-master:~$ 





图 5-48 


这 里 只 有 一 个 Pod, 不 过 RESTARTS 为 3， 而 且 不 断 增加 ， 说 明 OnFailure 生效 ， 容 
器 失败 后 会 自动 重启 。 








5.3.2 Job 的 并 行 性 


有 时 我 们 希望 能 同时 运行 多 个 Pod, 提高 Job 的 执行 效率 。 这 个 可 以 通过 parallelism 设 
置 ， 如 图 5-49 所 示 。 


43 


apiVersion: batch/vi 
kind: Job 
metadata 

name: myjob 


E 


metadata 
name: myjob 
spec 
containers 
name: hello 
image: busybox 
command 9 
restartPolicy: OnFoilure 





图 5-49 
这 里 我 们 将 并 行 的 Pod 数量 设置 为 2， 实 践 一 下 ， 如 图 5-50 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 

job "myjob" created 

ubuntuék8s-master:-$ 

ubuntuek8s-master:-$ kubectl get job 

NAME DESIRED SUCCESSFUL AGE 

myjob <none> 2 6s 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod --show-all -o wide 

NAME REAI STATUS RESTARTS AGE IP NODE 
myjob-cn4zs 0/1 Completed 0 12s 10.244.2.5 k8s-node2 
myjob-vhpzs 0/1 Completed 0 125 10.244.1.28 — k8s-nodel 
ubuntuék8s-master:- 








图 5-50 


Job 一 共 启 动 了 两 个 Pod， 而 且 AGE 相同 ， 可 见 是 并 行 运行 的 。 
我 们 还 可 以 通过 completions 设置 Job 成 功 完成 Pod 的 总 数 ， 如 图 5-51 所 示 。 


apiVersion: batch/v1 
kind: Job 
metadata 
пате: myjob 
spec 
completions 
template 
metadata 
name: myjob 
spec: 
containers 
- name: hello 
image: busybox 
соттапа: [ y 
restartPolicy: OnFailure 





图 5-51 


上 面 配置 的 含义 是 : 每 次 运行 两 个 Pod， 直 到 总 共有 6 个 Pod 成 功 完成 。 实践 一 下 ， 如 


图 5-52 所 示 。 
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ubuntuek8s-mast 
ubuntue@k8s-mast! kubectl apply -f myjob.yml 
job "myjob" created 


kubectl get job 
SUCCESSFUL] AGE 
6 9s 
ubuntuek8s-mast: 
ubuntu&k8s-master 
ubuntuék8s-master:-$ kubectl get pod --show-all -o wide 
STATUS RESTARTS АСЕ NODE 
Completed 0 16s .244.2. k8s-node2 
Completed 0 11s .244.2. k8s-node2 
Completed 0 145 ‚244.1. k8s-node1 
у Conpleted 
myjob-srpg9 Conpleted 
myjob-wl8tt — 0/ Completed 
ubuntuek8s-master: 


13s : mas k8s-node2 
12s К85-поде1 


9 
o 16s 10.244.1. k8s-node1 





K 5-52 


DESIRED 和 SUCCESSFUL 均 为 6, 符合 预期 。 如 果 不 指定 completions 和 parallelism, 
默认 值 均 为 1。 

上 面 的 例子 只 是 为 了 演示 Job 的 并 行 特性 ， 实 际 用 途 不 大 。 不 过 现实 中 确实 存在 很 多 需 
要 并 行 处 理 的 场景 。 比 如 批 处 理 程序 ， 每 个 副本 (Рой) 都 会 从 任务 池 中 读 取 任务 并 执行 ， 副 
本 越 多 ， 执 行 时 间 就 越 短 ， 效 率 就 越 高 。 这 种 类 似 的 场景 都 可 以 用 Job 来 实现 。 





5.8.8 定时 Job 


Linux 中 有 cron 程序 定时 执行 任务 ，Kubernetes 的 CronJob 提供 了 类 似 的 功能 ， 可 以 
定时 执行 Job. CronJob 配置 文件 示例 如 图 5-53 所 示 。 


apiVersion: batch/v2alphai 
kind: CronJob 
metadata 

name: hello 
spec 

schedule 

jobTemplate 

spec 


template 


spec 
containers 
- name: hello 
image: busybox 
command ; 
restartPolicy: OnFailure 





图 5-53 


@ batch/v2alphal 是 当前 CronJob 的 apiVersion. 

© 指明 当前 资源 的 类 型 为 CronJob。 

@ schedule 指定 什么 时 候 运行 Job， 其 格式 与 Linux cron 一 致 。 这 里 */1 * *** 的 含 
义 是 每 一 分 钟 启动 一 次 。 

@ jobTemplate 定义 Job 的 模板 ， 格 式 与 前 面 的 Job 一 致 。 

接 下 来 通过 kubectl apply 创建 CronJob， 如 图 5-54 所 示 。 





45 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f cronjob.yml 


error: error validating "cronjob.yml": error valideting data: the server could not find th 
resource; if you choose to ignore these errors, turn validation off with --validate-false 
ubuntu&kSs-master:-$ 





图 5-54 


失败 了 。 这 是 因为 Kubernetes 默认 没有 enable CronJob 功能 ， 需 要 在 kube-apiserver 中 
加 入 这 个 功能 。 方 法 很 简单 ， 修 改 kube-apiserver 的 配置 文件 /etc/kubernetes/manifests/kube- 
apiserver.yaml， 如 图 5-55 所 示 。 


apiVersion: v1 
kind: Pod 
metadata 
annotations: 
scheduler.alpha.kubernetes.io/critical-pod: 
creationTimestamp 
labels 
component: kube-apiserver 
tier: control-plane 
name: kube-apiserver 
namespace: kube-system 
spec: 
containers 
- command: 


requestheader-group-header: -Remote-Group 
requestheader-extra-headers-prefi -Remote-Extra- 
requestheader-allowed-names-front-proxy-client 
kubelet-client-key-/etc/kubernetes/pki/apiserver-kubelet-clien 
kubelet-preferred-address-types-InternalIP,ExternalIP,Hostname 
allow-privileged- 

experimental-bootstrap-token-auth- 
requestheader-username-headers-X-Remote-User 
Sservice-account-key-file-/etc/kubernetes/pki/sa.pub 





图 5-55 


kube-apiserver 本 身 也 是 一 个 Pod， 在 启动 参数 中 加 上 --runtime-config-batch/v2alphal 
=true 即 可 。 然 后 重启 kubelet 服务 : 


systemctl restart kubelet.service 














kubelet 会 重启 kube-apiserver Pod. 通过 kubectlapi-versions 确认 kube-apiserver 现 
经 支持 batch/v2alphal, ШШ 5-56 所 示 。 
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如 图 





ubuntuék8s-master:-$ 
ubuntuek8s-master kubectl api-versions 
apiextensions.k8s.io/vibetai 
apiregistration.k8s.io/vibetal 
apps/vibetal 
authentication.k8s.io/vi 
authentication.k8s.io/vibetal 
authorization.k8s.io/vl 
authorization.k8s.io/vibetal 
autoscaling/v1 

batch/vi 


tch/v2alphal 


extensions/vibetal 
networking.k8s.io/v1 
policy/vlbetal 
rbac.authorization.k8s.io/vialphai 
rbac.authorization.k8s.io/vibetal 
settings.k8s.io/vialphai 
storage.k8s.io/vi 
storage.k8s.io/vibetail 

v1 

ubuntuék8s-master :~$ 





图 5-56 
再 次 创建 CronJob， 如 图 5-57 所 示 。 


ubuntu@k8s-master :~$ 

ubuntuék8s-master:-$ kubectl apply -f cronjob.yml 
cronjob "hello" created 

ubuntuék8s-master :~$ 





图 5-57 
这 次 成 功 了 。 通 过 kubectl get cronjob 查看 CronJob 的 状态 ， 如 图 5-58 所 示 。 


ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get cronjob 

NAME SCHEDULE SUSPEND ACTIVE —— LAST-SCHEDULE 

hello */1* ** * False 9 Tue, 12 Sep 2017 10:21:00 +0800 
ubuntuék8s-master:-$ 





图 5-58 


等 待 几 分 钟 ， 然 后 通过 kubectl getjobs 查看 Job 的 执行 情况 ， 如 图 5-59 所 示 。 


ubuntuék8s-master:-$ kubectl get jobs 
NAME DESIRED SUCCESSFUL 
hello-1505181600 1 1 
hello-1505181660 


hello-1505181720 


1 
1 
hello-1505181780 1 
һе110-1505181840 1 
hello-1505181900 1 
ubuntuék8s-master:-$ 





图 5-59 


可 以 看 到 每 隔 一 分 钟 就 会 启动 一 个 Job. 执行 kubectl logs 可 查看 某 个 Job 的 运行 日 志 ， 
5-60 所 示 。 
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ubuntuék8s -master:-$ 

ubuntuék8s-master:-$ kubectl get pod --show-all 

NAME READY — STATUS RESTARTS AGE 
hello-1505181600-0hrxS 0/1 Completed @ 5m 
hello-1505181660-nbgwd 0/1 Completed ат 
һе110-1505181720-1359 0/1 Completed 3m 
lhello-1505181780-tjhq. 9/1 Completed 2m 


lhello-1505181840-lqdbv 09/1 Completed 1m 
lhello-1505181900-ggfr2 0/1 Completed 10s 
lubuntuek8s master :-$ 

jubuntuek8s-master:-$ kubectl logs hello-1505181720-1f350 
hello k8s job! 

ubuntu@k8s-master:~$ 





图 5-60 


5.4 Ië 


运行 容器 化 应 用 是 Kubernetes 最 重要 的 核心 功能 。 为 满足 不 同 的 业务 需要 ，Kubernetes 
提供 了 多 种 Controller， 包 括 Deployment、DaemonSet、Job、CronJob 等 。 本 章 我 们 通过 实践 
详细 学 习 了 这 些 Controller， 并 讨论 了 它们 的 特性 和 应 用 场景 。 
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са ¿= 


第 6 = 
iBiJ Service 访问 Pod 


我 们 不 应 该 期 望 Kubernetes Pod. 是 健壮 的 , 而 是 要 假设 Pod 中 的 容器 很 可 能 因为 各 种 原 
因 发 生 故 障 而 死 掉 。Deployment 等 Controller 会 通过 动态 创建 和 销毁 Pod 来 保证 应 用 整体 
的 健壮 性 。 换 句 话 说，Pod 是 脆弱 的 ， 但 应 用 是 健壮 的 。 
每 个 Pod 都 有 自己 的 IP 地 址 。 当 Controller 用 新 Pod 替代 发 生 故 障 的 Pod 时 ， 新 
Pod 会 分 配 到 新 的 IP 地 址 。 这 样 就 产生 了 一 个 问题 : 
如 果 一 组 Pod 对 外 提供 服务 (比如 HTTP) ， 它 们 的 IP 很 有 可 能 发 生变 化 ， 那 么 客户 
端 如 何 找到 并 访问 这 个 服务 呢 ? 

Kubernetes 给 出 的 解决 方案 是 Service。 











创建 Service 


Kubernetes Service 从 逻辑 上 代表 了 一 组 Pod， 有 具体 是 哪些 Pod 则 是 由 label 来 挑选 的 。 
Service 有 自己 的 IP,， 而 且 这 个 IP 是 不 变 的。 客户 端 只 需要 访问 Service 的 IP, Kubernetes 
则 负责 建立 和 维护 Service 与 Pod 的 映射 关系 。 无 论 后 端 Pod 如 何 变化 ， 对 客户 端 不 会 有 
任何 影响 ， 因 为 Service 没有 变 。 

来 看 个 例子 ， 创 建 下 面 的 这 个 Deployment, Auf 6-1 所 示 。 

apiVersion: аррѕ/у1бе+а1 


kind: Deployment 
metadata 


metadata 


abels 
httpd 


spec: 
containers 
- name: httpd 
image: httpd 
ports: 
- containerPort: 





6-1 


我 们 启动 了 三 个 Pod, 运行 httpd 镜像 , label 是 гип: httpd, Service 将 会 用 这 个 label Ж 
挑选 Pod， 如 图 6-2 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 
deployment "httpd" created 

ubuntuék8s-master: ~$ 

ubuntuek8s-master:-$ kubectl get pod -o wide 





NAME READY STATUS RESTARTS AGE NODE 
httpd-741508562-192vp 1/1 Running 0 1т > 4. k8s-node1 
httpd-741508562-6g4fc 1/1 Running 0 1m р 4. k8s-node1 
httpd-741508562-6hh9g 1/1 Running 0 1m * NP k8s-node2 
ubuntuek8s-master: -$ 

图 62 


Pod 分 配 了 各 自 的 IP, 33085 IP. 只 能 被 Kubernetes Cluster 中 的 容器 和 节点 访问 ， 如 图 6-3 
所 示 。 
接 下 来 创建 Service， 其 配置 文件 如 图 6-4 所 示 。 


apiVersion: vl 

kind: Service 

metadata 

name: httpd-svc 

spec 
ubuntu@k8s-master:~$ selector 
ubuntu@k8s-master:~$ curl 10.244.4.5 гип: httpd 
<html><body><h1>It works!«/h1»«/body»«/html» ports 
ubuntu@k8s-master:~$ - protocol: TCP 
ubuntu@k8s-master:~$ curl 10.244.5.4 port 
<html><body><h1>It works!«/h1»«/body»«/html» targetPort: 
ubuntu@k8s-master:~$ 





图 6-3 图 6-4 


Q) vl 是 Service 的 apiVersion。 
@ 指明 当前 资源 的 类 型 为 Service。 
@) Service 的 名 字 为 httpd-svc。 

@ selector 指明 挑选 那些 label 为 run: httpd 的 Pod 作为 Service 的 后 端 。 
@ 将 Service 的 8080 端口 映射 到 Pod 的 80 端口 ， 使 用 TCP 协议 。 

执 





行 kubectl apply 创建 Service httpd-svc， 如 图 6-5 所 示 。 


ubuntu@k8s-master :~$ 

ubuntuék8s-master:-$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" created 

ubuntu@k8s-master:~$ 

ubuntuék8s-master:-$ kubectl get service 


NAME CLUSTER-IP EXTERNAL-IP РОКТС5) AGE 
httpd-svc 10.99.229.179 «none» 8080/TCP 75 
kubernetes 10.96.0.1 <none> 443/TCP 2d 
ubuntuek8s-master:-$ 





图 6-5 


httpd-svc 分 配 到 一 个 CLUSTER-IP 10.99.229.179。 可 以 通过 该 IP 访问 后 端的 httpd 
Pod， 如 图 6-6 所 示 。 
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ster:~$ curl 10.99.229.179:8080 


h1>It works!«/h1»«/body»«/html» 





图 6-6 


根据 前 面 的 端口 映射 ， 这 里 要 使 用 8080 端口 。 另 外 ， 除 了 我 们 创建 的 httpd-svc， 还 有 
-个 Service kubernetes, Cluster 内 部 通过 这 个 Service 访问 Kubernetes API Server. 
通过 kubectl describe 可 以 查看 httpd-svc 与 Pod 的 对 应 关系 ， 如 图 6-7 所 示 。 


ubuntuêk8s-master :~$ 
ubuntuék8s-master:-$ kubectl describe service httpd-svc 
Nane: httpd-svc 
Namespace : default 
Labels: «none» 
Annotations: kubectl.kubernetes.io/last-applied-configuration: 
:8080, "protocol":"TC... 
Selector: run-httpd 

: ClusterIP 

10.99.229.179 
t» 8080/TCP 
































<попе> 
ubuntuek8s-master:-$ 





图 6-7 


Endpoints 罗列 了 三 个 Pod 的 IP 和 端口 。 我 们 知道 Pod 的 IP 是 在 容器 中 配置 的 ， 那 
Z Service 的 Cluster IP 又 是 配置 在 哪里 的 呢 ? CLUSTER-IP 又 是 如 何 映射 到 Pod IP 的 
呢 ? 

答案 是 iptables. 


< Cluster IP 底层 实现 


Cluster IP. 是 一 个 虚拟 IP， 是 由 Kubernetes 节点 上 的 iptables 规则 管理 的 。 
可 以 通过 iptables-save 命令 打印 出 当前 节点 的 iptables 规则 ， 因 为 输出 较 多 ， 这 里 只 截 
取 与 httpd-svc Cluster IP 10.99.229.179 相关 的 信息 ， 如 图 6-8 所 示 。 


-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.99.229.179/32 -p tcp -m comment -comment “default/httpd-svc: 
Cluster IP" -m tcp -dport 8080 —j KUBE-MARK-MASQ 























-A KUBE-SERVICES -d 10.99.229.179/32 -p tcp -m comment -comment "default/httpd-svc: Cluster IP" -m tcp 
-dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP 





图 6-8 


这 两 条 规则 的 含义 是 : 
(1) WR Cluster 内 的 Pod ( 源 地 址 来 自 10.244.0.0/16) 要 访问 httpd-sve， 则 允许 。 
(2) 其 他 源 地 址 访问 httpd-svc， 跳 转 到 规则 KUBE-SVC-RL3JAE4GN7VOG DGP。 


KUBE-SVC-RL3JAE4GN7VOGDGP 规则 如 图 6-9 所 示 。 
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-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment "default/httpd-svc: " -m 
statistic -mode random -probability 0.33332999982 -j KUBE-SEP-C5KB52P4BBJQ35PH 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment "default/httpd-svc: " -m statistic -mode random -prob 
ability 0.33332999982 -j KUBE-SEP-C5KB52P4BBJQ35PH 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment "default/httpd-svc: " -m statistic -mode random -prob 
ability 0.50000000000 -j KUBE-SEP-HGVKQQZZCF7RV4IT 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment "*default/httpd-svc: " -j KUBE-SEP-XE25WGVXLHEIRVOS 





图 6-9 


(1) 1/3 的 概率 跳 转 到 规则 KUBE-SEP-CSKB52P4BBJQ35PH. 
(2) 1⁄3 的 概率 GIF 2/3 的 一 半 ) 跳 转 到 规则 KUBE-SEP-HGVKQQZZCF7RV4IT。 
(3) 1/3 的 概率 跳 转 到 规则 KUBE-SEP-XE25WGVXLHEIRVO5。 


上 面 三 个 跳 转 的 规则 如 图 6-10 所 示 。 


-A KUBE-SEP-C5KBS2P4BBJQ35PH -s 10.244.4.4/32 -m comment --comment "default/httpd-svc:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-C5KB52P4BBJQ35PH -p tcp -m comment --comment "default/httpd-svc:" -m tcp -j DNAT --to-destination 10.244.4.4:80 
-A KUBE-SEP-HGVKQQZZCF7RVAIT -s 10.244.4.5/32 -m comment --comment "default/httpd-svc:" -j KUBE-MARK-MASQ 


-A KUBE-SEP-HGVKQQZZCF7RVAIT -p tcp -m comment --comment "default/httpd-svc:" -m tcp -j DNAT --to-destination 10.244.4,5:80 
-A KUBE-SEP-XE25WGVXLHEIRVOS -s 10.244.5.4/32 -m comment --comment "default/httpd-svc:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-XE25WGVXLHEIRVOS -p tcp -m comment --comment "default/httpd-svc:" -m tcp -j DNAT --to-destination 10.244.5.4:80 





图 6-10 


即将 请 求 分 别 转发 到 后 端的 三 个 Pod。 通 过 上 面 的 分 析 ， 我 们 得 到 结论 : iptables 将 访问 
Service 的 流量 转发 到 后 端 Poad， 而 且 使 用 类 似 轮 询 的 负载 均衡 策略 。 

另外 ， 需 要 补充 一 点 : Cluster 的 每 一 个 节点 都 配置 了 相同 的 iptables 规则 ， 这 样 就 确保 
了 整个 Cluster 都 能 够 通过 Service 的 ClusterIP 访问 Service, WA 6-11 所 示 。 


10.99.229.179 
Cluster IP 
(iptables) 
10.99.229.179 10.99.229.179 
Cluster IP Cluster IP 
(iptables) (iptables) 
httpd-741508562-192vp 
10.2444.5 SACRUM. 
httpd-741508562-6g4fc. 
1024444 
图 6-11 
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DNS 访问 Service 


在 Cluster 中 ， 除 了 可 以 通过 Cluster IP 访问 Service，Kubernetes 还 提供 了 更 为 方便 的 
DNS 访问 。 
kubeadm 部 署 时 会 默认 安装 kube-dns 组 件 ， 如 图 6-12 所 示 。 


ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ kubectl get deployment --namespace-kube-system 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kube-dns 1 1 1 1 54 
ubuntu@k8s-master:~$ 





图 6-12 


kube-dns 是 一 个 DNS 服务 器 。 每 当 有 新 的 Service 被 创建 ，kube-dns 会 添加 该 Service 
的 DNS 记录 。Cluster 中 的 Pod 可 以 通过 <SERVICE МАМЕ>.<МАМЕЅРАСЕ NAME> Ùj 
问 Service。 

比如 可 以 用 httpd-svc.default 访问 Service httpd-svc， 如 图 6-13 所 示 。 


ubuntuk8s master: -$ 

ubuntuek8s-master:-$ kubectl run busybox --rm -ti --image-busybox /bin/sh 

If you don't see a command prompt, try pressing enter. 

^g 

Connecting to httpd-svc.defoult:8080 (10.99.229.179:8080) 

ЕСЕ ат 100% |е#еекеневњененео веноз аввоневезноноковоноковкоковнене! 


"n 





图 6-13 


如 上 所 示 ， 我 们 在 一 个 临时 的 busybox Pod 中 验证 了 DNS 的 有 效 性 。 另 外 ， 由 于 这 个 
Pod 与 httpd-sve 同属 于 default namespace， 因 此 可 以 省 略 default 直接 用 httpd-svc 访问 
Service， 如 图 6-14 所 示 。 


"n 

/ # wget[httpd-svc:8080 

Connecting to httpd-svc:8080 (10.99.229.179:8080) 

Rndéx html EI "———— 45 0:00:00 ЕТА 
ul 




















图 6-14 














H nslookup 查看 httpd-svc 的 DNS 信息 ， 如 图 6-15 所 示 。 


/# 
/ # nslookup httpd-svc 
10.96.0.10 

: 10.96.0.10 kube-dns .kube-system.svc.cluster.local 


httpd-svc 
: 10.99.229.179 httpd-svc.default.svc.cluster.local 





图 6-15 


DNS 服务 器 是 kube-dns.kube-system.svc.clusterlocal， 这 实际 上 就 是 kube-dns 组 件 ， 它 
本 身 是 部 署 在 kube-system namespace 中 的 一 个 Service。 
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httpd-svc.default.svc.cluster.local 是 httpd-svc 的 完整 域名 。 
如 果 要 访问 其 他 namespace 中 的 Service， 就 必须 带 上 namesapce 了 。kubectl get 
namespace 查看 已 有 的 namespace， 如 图 6-16 所 示 。 


ubuntu@k8s-master:~$ 

ubuntuek8s-master:-$ kubectl get namespace 
NAME STATUS AGE 

default Active 5d 


kube-public Active 54 
kube-system Active 54 
ubuntuék8s-naster :~$ 


图 6-16 


YE kube-public 中 部 署 Service httpd2-svc, BO EA 6-17 所 示 。 








apiVersion: apps/vibetal 
kind: Deployment 
metadata 


replicas 
template 
metadata 
labels 
run: httpd2 
spec: 
containers: 
name: httpd2 
image: httpd 
ports 
- containerPort 


apiVersion: v1 
kind: Service 
metadata 
па httpd2-svc 
namespace: kube-public 
5рес 
selector 
гип: httpd2 
ports 
- protocol: TCP 
port 
targetPort: 





图 6-17 


通过 namespace: kube-public 指定 资源 所 属 的 namespace。 多 个 资源 可 以 在 一 个 YAML 
文件 中 定义 ， 用 “---” 分 割 。 执 行 kubectl apply 创建 资源 ， 如 图 6-18 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master kubectl apply -f httpd2.yml 
deployment "httpd2" created 





service "httpd2-svc" created 
ubuntuék8s-master:-$ 





图 6-18 
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查看 kube-public 的 Service， 如 图 6-19 所 示 。 


ubuntuêk8s-master :~$ 
ubuntu@k8s-master:-$ kubectl get service --namespace-kube-public 
NAME CLUSTER-IP EXTERNAL-IP РОВТ(5) AGE 


httpd2-svc 10.103.198.189 <none> 8080/TCP 2m 
ubuntuek8s-master:-$ 





图 6-19 


TE busybox Pod 中 访问 Һира2-ѕус, ШІ 6-20 所 示 。 


ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl run busybox --rm -ti --image-busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/x* 

/ # wget wget httpd2-svc:8080 

wget: bad address 'wget' 


А 
/ # wget httpd2-svc.kube-public:8080 
Connecting to httpd2-svc.kube-public:8080 (10.103.198.189:8080) 


index.html 100% |WXAXdakxdxdkEEXASEEXEREREEEEXEEKEREEEERERKEREKREREREKIRE| 45 0:00:00 ETA 





/ # 


图 6-20 


因为 不 属于 同一 个 namespace， 所 以 必须 使 用 httpd2-svc.kube-public 才能 访问 到 。 


6.4 外 网 如 何 访问 Service 


除了 Cluster 内 部 可 以 访问 Service， 很 多 情况 下 我 们 也 希望 应 用 的 Service 能 够 暴露 给 
Cluster 外 部 。Kubernetes 提供 了 多 种 类 型 的 Service， 默 认 是 ClusterIP. 


(1) ClusterIP 
Service 通过 Cluster 内 部 的 IP 对 外 提供 服务 ， 只 有 Cluster 内 的 节点 和 Pod 可 访问 ， 
这 是 默认 的 Service 类 型 ， 前 面 实验 中 的 Service 都 是 ClusterIP。 


(2) NodePort 
Service 通过 Cluster 节点 的 静态 端口 对 外 提供 服务 Cluster 外 部 可 以 通过 
<NodeIP>:<NodePort> 访问 Service. 


(3) LoadBalancer 

Service 利用 cloud provider 特有 的 load balancer 对 外 提供 服务 ，cloud provider 负责 将 
load balancer 的 流量 导向 Service。 目 前 支持 的 cloud provider 有 GCP, AWS, Azur 等 。 

下 面 我 们 来 实践 NodePort，Service httpd-svc 的 配置 文件 修改 如 图 6-21 所 示 。 
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apiVersion: vi 

kind: Service 

metadata 
name 

s 


httpd-svc 


electoi 
run: httpd 
ports 
protocol: TCP 
port 
targetPort 





图 621 








添加 type: NodePort, 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master 
Service "httpd-svc" created 
ubuntuék8s-master:-: 
ubuntu&k8s-master 

NAME CLUSTER-IP 
httpd-svc 10.109.144.35 
ubuntu&k8s-master:-$ 


EXTERNAL 
<nodes> 


图 6-22 


新 创建 httpd-svc， 如 图 6-22 所 示 。 


-$ kubectl apply -f httpd-svc.yml 





Kubernetes 依然 会 为 httpd-svc 分 配 一 个 ClusterIP， 不 同 的 是 : 


(1) EXTERNAL-IP 为 nodes， 表 示 可 通过 Cluster 每 个 节点 自身 的 IP 访问 Service。 
(2) PORT(S) 为 8080:32312。8080 是 ClusterIP 监听 的 端口 ，32312 则 是 节点 上 监听 





的 端口 。Kubernetes 会 从 30000 ~ 32767 中 分 配 一 个 可 用 的 端 
并 将 请 求 转发 给 Service， 如 图 6-23 所 示 。 











netstat 
2312 
ubuntuek8s-mastei 





图 6-23 


下 面 测试 NodePort 是 否 正常 工作 ， 如 图 6-24 所 示 。 


ubuntu®k8s-master :~$ 














， 每 个 节点 都 会 监听 此 端口 


LISTEN 


ubuntuek8s-master:-$ curl 192.168.56.105:32312 
«html»«body»«h1»It works!«/h1»«/body»«/html» 


ubuntuék8s -master:-$ 


ubuntuék8s-master:-$ curl 192.168.56.106:32312 


«html»«body»«h1»It works!«/h1»«/body»«/html» 
ubuntuék8s -master:-$ 
ubuntuék8s-master:-$ curl 192.168.56.107:32312 
«html»«body»«h1»It works!«/h1»«/body»«/html» 

ubuntuék8s-master:-$ 


图 6-24 


通过 三 个 节点 IP-32312 端口 都 能 够 访问 httpd-svc. 





接 下 来 我 们 深入 探讨 一 个 问题 : Kubernetes 是 如 何 将 <NodeIP>:<NodePort> 映射 到 Pod 
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的 呢 ? 
与 ClusterIP 一 样 ， 也 是 借助 了 iptables. Í ClusterIP 相 比 ， 每 个 节点 的 iptables 中 都 
增加 了 下 面 两 条 规则 ， 如 图 6-25 所 示 。 


-A KUBE-NODEPORTS -p tcp -m comment -comment *default/httpd-svc: " -m tcp --dport 32312 -j KUBE-MARK-M 
ASQ 


-A KUBE-NODEPORTS -p tcp -m comment -comment “default/httpd-svc: ” -m tcp --dport 32312 -j KUBE-SVC-RL 
3JAE4GN7VOGDGP 





图 6-25 


规则 的 含义 是 : 访问 当前 节点 32312 端口 的 请 求 会 应 用 规则 KUBE-SVC-RL3JAE4GN7 VOGDGP, 
内 容 如 图 6-26 所 示 。 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 
ability 0.33332999982 -j KUBE-SEP-C5KB52P4BBJQ35PH 

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 
ability 0.50000000000 -j KUBE-SEP-HGVKQQZZCF7RVAIT 

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -j KUBE-SEP-XE25WGVXLHEIRVOS 





图 6-26 


其 作用 就 是 负载 均衡 到 每 一 个 Pod. 
NodePort 默认 的 是 随机 选择 ， 不 过 我 们 可 以 用 nodePort 指定 某 个 特定 端口 ， 如 图 6-27 所 示 。 


apiVersion: v1 
kind: Service 
metadata 

name: httpd-svc 
spec 

type: NodePort 
selector 


run: httpd 
ports: 
rotocol 
port 
targetPort 





图 6-27 
现在 配置 文件 中 就 有 三 个 Pot T: 


€  nodePort 是 节点 上 监听 的 端口 。 
€ port 是 ClusterIP 上 监听 的 端口 。 
€ targetPort Ж Pod 监听 的 端口 。 


Je, Node 和 ClusterIP 在 各 自 端口 上 接收 到 的 请 求 都 会 通过 iptables 转发 到 Pod 的 
targetPort 。 
应 用 新 的 nodePort 并 验证 ， 如 图 6-28 所 示 。 
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ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" configured 
ubuntuek8s-master:-$ 
-$ kubectl get service httpd-svc 

CLUSTER-IP EXTERNAL -IP PORT(S) AGE 
httpd-svc 10.109.144.35 «nodes» 8080:30000/TCP — 36m 
ubuntuek8s-master: 


ubuntuek8s-maste curl 192.168.56.105:30000 
«html»«body»«hi»It works!«/h1»«/body»«/html» 
ubuntuék8s-master:-$ curl 192.168.56.106:30000 
<html><body><h1>It works!</hl></body></html> 
ubuntuek8s-master:~$ curl 192.168.56.107:30000 
«html»«body»«hl»It works!«/hl»«/body»«/html» 
ubuntuek8s-master:-$ 





图 6-28 





nodePort: 30000 已 经 生效 了 。 


5 小 结 





本 章 我 们 讨论 访问 应 用 的 机 制 Service， 学 习 了 如 何 创建 Service, Service 的 三 种 类 型 
ClusterIP、NodePort 和 LoadBalancer， 以 及 它们 各 自 的 适用 场景 。 
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第 7 章 
Rolling Update 


滚动 更 新 是 一 次 只 更 新 一 小 部 分 副本 ， 成 功 后 再 更 新 更 多 的 副本 ， 最 终 完成 所 有 副本 的 更 新 。 
滚动 更 新 的 最 大 好 处 是 零 停机 ， 整 个 更 新 过 程 始 终 有 副本 在 运行 ， 从 而 保证 了 业务 的 连续 性 。 


实践 


下 面 我 们 部 署 三 副本 应 用 ， 初 始 镜像 为 httpd:2.2.31， 然 后 将 其 更 新 到 httpd:2.2.32。 
httpd:2.2.31 的 配置 文件 如 图 7-1 所 示 。 


apiVersion: apps/vibetai 
kind: Deployment 
metadata: 

name: httpd 
spec: 

replicas: 

template 

metadata 


labels 


run: httpd 
spec: 
containers: 


name: httpd 
ports 
- containerPort: 





7-1 
通过 kubectl apply 部 署 ， 如 图 7-2 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 
deployment "httpd" created 
~$ 
kubectl get deployment httpd -o wide 
CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) SELECTOR 
а 3 2 85 httpd 31] run-httpd 
e$ 
ubuntuék8s-master:-$ kubectl get replicaset -o wide 
INAME DESIRED CURRENT READY AGE CONTAINERCS) SELECTOR 
httpd-551879778 3 3 3 13s httpd pod-template-hash=55 
~$ 
READY STATUS RESTARTS 
httpd-551879778-jkxn4 1⁄1 Running 
httpd-551879778-n3sqv 1⁄1 Running 


httpd-551879778-zdfkt 1/1 Running 
ubuntuek8s-master :~$ 





图 7-2 
部 署 过 程 如 下 : 
(1) 创建 Deployment httpd。 
(2) 创建 ReplicaSet httpd-551879778 。 
(3) 创建 三 个 Pod。 
(4) 当前 镜像 为 httpd:2.2.31。 


kubectl apply -f httpd.yml 

deployment "httpd" configured 

ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT  UP-TO-DATE AVAILABLE АСЕ CONTAINERCS) SELECTOR 
httpd E 3 3 3 1n httpd run-httpd 
ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl get replicaset -o wide 

NAME DESIRED CURRENT READY AGE CONTAINER(S) IMAGE(S) SELECTOR 
httpd-1276601241 3 3 3 9s httpd pod-template-hash: 
httpd-551879778 0 0 9 E httpd pod-template-hash: 
ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl get pod 

NAME READY STATUS RESTARTS АСЕ 

httpd-1276601241-26jx3 1⁄4 Running 13s 

httpd-1276601241-27kh7 1/1 Running 10s 

httpd-1276601241-pwrt?7 1/1 Running 11s 

ubuntuék8s-master:-$ 





图 7-3 
我 们 发 现 了 如 下 变化 : 
(1) Deployment httpd 的 镜像 更 新 为 httpd:2.2.32。 


(2) 新 创建 了 ReplicaSet httpd-1276601241， 镜 像 为 httpd:2.2.32， 并 且 管 理 了 三 个 新 的 Pod。 
(3) 之 前 的 ReplicaSet httpd-551879778 里 面 已 经 没有 任何 Pod. 





结论 是 : ReplicaSet httpd-551879778 的 三 个 httpd:2.2.31 Pod 已 经 被 ReplicaSet 
httpd-1276601241 的 三 个 httpd:2.2.32 Pod 替换 了 。 
具体 过 程 可 以 通过 kubectl describe deployment httpd 查看 ， 如 图 7-4 所 示 。 
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deploynent-controller |gReplicaSet wp replico set httpd-551879778 to 3 
deploynent-controller ScolingReplicaSet Scaled up replica set httpd-1276601241 to 1 
deployment-controller ScolingReplicoSet Scoled down replico set httpd-551879778 to 2 


deployment-controller ScolingReplicoSet Scoled up replico set httpd-1276601241 to 2 
deployment-controller ScalingReplicaSet Scaled down replica set httpd-551879778 to 1 
deployment-controller ScolingReplicoSet Scoled up replica set httpd-1276601241 to 3 
deployment-controller ScolingReplicoSet Scoled down replico set httpd-551879778 to @ 





图 74 
每 次 只 更 新 替换 一 个 Pod: 


(1) ReplicaSet httpd-1276601241 增加 一 个 Pod， 总 数 为 1。 
(2) ReplicaSet httpd-551879778 减少 一 个 Pod， 总 数 为 2。 
(3) ReplicaSet httpd-1276601241 增加 一 个 Pod， 总 数 为 2。 
(4) ReplicaSet httpd-551879778 减少 一 个 Pod， 总 数 为 1。 
(5) ReplicaSet httpd-1276601241 增加 一 个 Pod， 总 数 为 3。 
(6) ReplicaSet httpd-551879778 减少 一 个 Pod， 总 数 为 0. 


БЕК Ж ЧАП Pod 数量 是 可 以 定制 的 。Kubemetes 提供 了 两 个 参数 maxSurge 和 
maxUnavailable 来 精细 控制 Pod 的 替换 数量 ， 我 们 将 在 后 面 结合 Health Check 特性 一 起 讨论 。 





< EZ 

kubectl apply 每 次 更 新 应 用 时 ，Kubernetes 都 会 记录 下 当前 的 配置 , 保存 为 一 个 revision 
(版 次 ) ， 这 样 就 可 以 回 滚 到 某 个 特定 revision, 

默认 配置 下 ，Kubernetes 只 会 保留 最 近 的 几 个 revision， 可 以 在 Deployment 配置 文件 中 
通过 revisionHistoryLimit 属性 增加 revision 数量 。 

下 面 实践 回 滚 功 能 。 应 用 有 三 个 配置 文件 , 即 httpd.vl.yml、 httpd.v2.yml 和 httpd.v3.yml, 
分 别 对 应 不 同 的 httpd 镜像 24.16. 24.17 和 2.4.18， 如 图 7-5、 图 7-6、 图 7-7 所 示 。 








apiVersion: apps/vibetal 
kind: Deployment 
metadata 
name: httpd 
5рес 
revisionHistoryLimit 
гер11са$ 
template 
metadata 
labels 
run: httpd 
spec 
containers 


name: httpd 
ports 
containerPort 





图 7-5 
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apiVersion: apps/v1beta1 apiVersion: apps/vibetai 
kind: Deployment kind: Deployment 
metadata metadata: 
name: httpd name: httpd 
5рес spec: 
revisionHistoryLimit revisionHistoryLimit 
replicas replicas: 
template template 
metadata metadata 
labels lobels 
run: httpd run: httpd 
spec spec 
containers containers: 
name: httpd - name: httpd 
ports ports: 
- containerPort containerPort 





图 7-6 图 7-7 
通过 kubectl apply 部 署 并 更 新 应 用 ， 如 图 7-8 所 示 。 


ubuntu&kBs-master: -$ 

ubuntu&k8s-master:-$ kubectl apply -f httpd.vl.ym (--record) 

deployment "http. 

ubuntuék8s-mastei 

ubuntuek8s-master:-$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) — IMAGECS7 SELECTOR 


httpd E E E] E 8з httpd httpd:2.4.16) run-httpd 


ubuntuekBs-master: -$ 

ubuntuek8s-maste kubectl apply -f httpd.v2.yml (record) 

deployment "httpd" configured 

ubuntuék8s-maste: 

ubuntuék8s-master:-$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) — IMAGECS) SELECTOR 
httpd 3 3 3 3 27s httpd run-httpd 


ubuntuék8s-master:-$ 
ubuntu@k8s-maste! kubectl apply -f httpd.v3.yml 
deployment "httpd" configured 
ubuntuék8s-mastei 
ubuntuék8s-master:-$ kubectl get deployment httpd -o wide 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) ІМАСЕСЅ SELECTOR 


3 3 3 3 515 httpd run-httpd 


ubuntuék8s-master:-$ 





图 7-8 


--record 的 作用 是 将 当前 命令 记录 到 revision 记录 中 ， 这 样 我 们 就 可 以 知道 每 个 revison 
对 应 的 是 哪个 配置 文件 了 。 通 过 kubectl rollout history deployment httpd 查看 revison 历史 记 
录 ， 如 图 7-9 所 示 。 


ubuntu@k8s-master: 

ubuntu@k8s-master:~$ kubectl rollout history deployment httpd 
deployments "httpd" 

REVISION CHANGE-CAUSE 


kubectl apply --filename-httpd.v1.yml --record=true 
kubectl apply --filename-httpd.v2.yml --record-true 
kubectl apply --filename-httpd.v3.yml --record-true 





ubuntuék8s-master:-$ 


FE 7-9 
CHANGE-CAUSE 就 是 --record 的 结果 。 如 果 要 回 滚 到 某 个 版 本 ， 比 如 revision 1， 可 以 
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执行 命令 kubectl rollout undo deployment httpd --to-revision=1， 如 图 7-10 所 示 。 


jubuntuek8s master : ~: 

ubuntuek8s-master:-$ kubectl rollout undo deployment httpd --to-revision-1 
deployment "httpd" rolled back 

ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 

МАМЕ DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) IMAGE(S SELECTOR 
httpd 3 3 3 3 8m httpd run=httpd 
ubuntu@k8s-master:~$ 





图 7-10 
此 时 ，revison 历史 记录 也 会 发 生 相应 变化 ， 如 图 7-11 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl rollout history deployment httpd 
deployments "httpd 

REVISION CHANGE-CAUSE 


kubectl apply --filena 
kubectl apply --filena 
kubectl apply --filename-httpd.v1.yml --record-true 





ubuntuek8s-master:-$ 


E 7-11 


revison 1 变 成 了 revison 4。 不 过 我 们 可 以 通过 CHANGE-CAUSE 知道 每 个 revison 的 
具体 含义 ， 所 以 一 定 要 在 执行 kubectl apply 时 加 上 --record 参数 。 





T 小 结 


本 章 我 们 学 习 了 滚动 更 新 。 滚 动 更 新 采用 渐进 的 方式 逐步 蔡 换 旧版 本 Pod。 如 果 更 新 不 如 
预期 ， 可 以 通过 回 滚 操 作 恢复 到 更 新 前 的 状态 。 
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第 8 = 


Health Check 


强大 的 自 愈 能 力 是 Kubernetes 这 类 容器 编排 引擎 的 一 个 习 





置 更 精细 的 健康 检查 ， 进 而 实现 如 下 需求 : 


(1) 零 停 机 部 署 。 
(2) 避免 部 署 无 效 的 镜像 。 
(3) 更 加 安全 的 滚动 升级 。 


下 面 通过 实践 学 习 Kubernetes 的 Health Check 功能 。 





默认 的 健康 检查 





下 要 特性 。 自 愈 的 默认 实现 方式 
是 自动 重启 发 生 故 障 的 容器 。 除 此 之 外 ， 用 户 还 可 以 利用 Liveness 和 Readiness 探测 机 制 设 


我 们 首先 学 习 Kubernetes 默认 的 健康 检查 机 制 : 每 个 容器 启动 时 都 会 执行 一 个 进程 ， 此 


进程 由 Dockerfile 的 CMD 或 ENTRYPOINT 指定 。 如 果 进 程 退出 时 返回 

















器 发 生 故 障 ，Kubernetes 就 会 根据 restartPolicy 重启 容器 。 





apiVersion: v1 
kind: Pod 
metadata: 

labels: 
test: healthcheck 

name: healthcheck 

spec: 

containers: 

- name: healthcheck 
image: busybox 
args: 

- /bin/sh 
cis 


图 8-1 





Pod 的 restartPolicy 设置 为 OnFailure， 默 认为 Always. 














面 我 们 模拟 一 个 容器 发 生 故 障 的 场景 ，Pod 配置 文件 如 图 8-1 所 示 。 


码 非 零 ， 则 认为 容 


sleep 10; exit 1 模拟 容器 启动 10 秒 后 发 生 故 障 。 
执行 kubectl apply 创建 Pod， 命 名 为 healthcheck， 如 图 8-2 所 示 。 


ubuntuéek8s -master:-$ 
ubuntuék8s-mast. kubectl apply -f healthcheck.yml 


pod "healthcheck" created 
ubuntu@k8s-master:~$ 





图 82 
几 分 钟 查看 Pod 的 状态 ， 如 图 8-3 所 示 。 


ubuntuék8s master :~$ 
ubuntuek8s-master:-$ kubectl get pod healthcheck 
NAME READY STATUS RESTARTS AGE 
healthcheck 1⁄1 Running 3 1т 
ubuntuék8s-master:-$ 





图 8-3 

可 看 到 容器 当前 已 经 重启 了 3 次 。 

在 上 面 的 例子 中 ， 容 器 进程 返回 值 非 零 ，Kubernetes 则 认为 容器 发 生 故障 ， 需 要 
有 不 少 情况 是 发 生 了 故障 , 但 进程 并 不 会 退出 。 比 如 访问 Web 服务 器 时 显示 500 内 部 错误 ， 
可 能 是 系统 超载 ， 也 可 能 是 资源 死 锁 ， 此 时 httpd 进程 并 没有 异常 退出 ， 在 这 种 情况 下 重 忆 
容器 可 能 是 最 直接 、 最 有 效 的 解决 方案 ， 那 我 们 如 何 利用 Health Check 机 制 来 处 理 这 类 场景 
呢 ? 

答案 就 是 Liveness 探测 。 























Liveness 探测 


Liveness 探测 让 用 户 可 以 自 定 义 判断 容器 是 否 健康 的 条 件 。 如 果 探 测 失败 , Kubernetes 就 
重启 容器 。 
下 面 举例 说 明 ， 创 建 Pod， 如 图 8-4 所 示 。 


apiVersion: vi 
kind: Pod 
metadata 
labels 
test: liveness 
name: liveness 
spec 
restartPolicy: OnFailure 
containers 
name: liveness 








image: busybox 
args 
/bin/sh 


touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; 
livenessProbe 
exec 
command 


cat 
/tmp/healthy 

initialDelaySeconds 

periodSeconds 





图 8-4 
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启动 进程 首先 创建 文件 /tmp/healthy, 30 秒 后 删除 ， 在 我 们 的 设 定 中 ， 如 果 /tmp/healthy 
文件 存在 ， 则 认为 容器 处 于 正常 状态 ， 反 之 则 发 生 故 障 。 
livenessProbe 部 分 定义 如 何 执行 Liveness 探测 : 


(1) 探测 的 方法 是 : 通过 cat 命令 检查 /tmp/healthy 文件 是 否 存 在 。 如 果 命 令 执行 成 功 ， 
































返回 值 为 零 , Kubernetes 则 认为 本 次 Liveness 探测 成 功 ; 如 果 命 令 返 回 值 非 零 , 本 次 Liveness 
探测 失败 。 
(2) initialDelaySeconds: 10 指定 容器 启动 10 之 后 开始 执行 Liveness 探测 ， 我 们 一 般 


会 根据 应 用 启动 的 准备 时 间 来 设置 。 比 如 某 个 应 用 正常 启动 要 花 30 秒 ， 那 么 
initialDelaySeconds 的 值 就 应 该 大 于 30。 

(3) periodSeconds: 5 指定 每 5 秒 执行 一 次 Liveness 探测 。 Kubernetes 如 果 连 续 执 行 3 
次 Liveness 探测 均 失败 ， 则 会 杀 掉 并 重启 容器 。 

下 面 创建 Pod liveness， 如 图 8-5 所 示 。 





ubuntuék8s master : ~f 
ubuntuek8s-master:-$ kubectl apply -f liveness.yml 


pod "liveness" created 
ubuntuek8s-master: ~$ 





图 8-5 


从 配置 文件 可 知 ， 最 开始 的 30 秒 ，/tmp/healthy 存在 ，cat 命令 返回 0，Liveness 探测 成 功 ， 
这 段 时 间 kubectl describe pod liveness 的 Events 部 分 会 显示 正常 的 日 志 ， 如 图 8-6 所 示 。 














uled Su fully assigned liveness to k8s-nodel 
Normal SuccessfulMountVolume ^ MountVolume.SetUp succeeded for volume "default-token-hnz7b" 
Normal Pulling pulling image "busybox" 
Normal Pulled Successfully pulled image "busybox" 
Normal Created Created container 





35 秒 之 后 ， 日 志 会 显示 /tmp/healthy 已 经 不 存在 ，Liveness 探测 失败 。 再 过 几 十 秒 ， 几 
次 探测 都 失败 后 ， 容 器 会 被 重启 ， 如 图 8-7、 图 8-8 所 示 。 


Type Reason 





Normal Scheduled ssfully assigned liveness to k8s-nodel 
Normal SuccessfulMountVolume — MountVolume.SetUp succeeded for volume "defoult-token-hnz7b' 
{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file 


Normal Pulling pulling image “busybox” 
Normal Killing Killing R Ker:77Tivenes: Gut (3UBGSUed-a32T-11e7-5229-0800274451ad)" cor] 


Normal Created Created container 
Normal Started Started container 





图 8-7 
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8s-master :~ 


ubuntuék8s-master:-$ kubectl get pod liveness 
NAME READY STATUS RESTAR AGE 
liveness 1/1 Running U 1m 


ubuntuêk8s-master : ~$ 





Readiness 探测 


除了 Liveness 探测 ，Kubernetes Health Check 机 制 还 包括 Readiness 探测 。 

用 户 通过 Liveness 探测 可 以 告诉 Kubernetes 什么 时 候 通过 重启 容器 实现 自 愈 ; 
Readiness 探测 则 是 告诉 Kubernetes 什么 时 候 可 以 将 容器 加 入 到 Service 负载 均衡 池 中 ， 对 
外 提供 服务 。 


Readiness 探测 的 配置 语法 与 Liveness 探测 完全 一 样 ， 如 图 8-9 中 的 例子 所 示 。 


apiVersion: у1 
kind: Pod 
metadata 
labels 
test: readiness 
name: readiness 
spec: 
restartPolicy: OnFailure 
containers 
name: readiness 
image: busybox 


args 
- /bin/sh 


- -c 


- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 


exec 
command 
cat 
/tmp/healthy 
initialDelaySeconds 
periodSeconds 





图 8-9 


这 个 配置 文件 只 是 将 前 面 例子 中 的 liveness 替换 为 了 readiness， 我 们 看 看 有 什么 不 同 的 
效果 ， 如 图 8-10 所 示 。 
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ubuntuék8s-master:-$ kubectl apply -f readiness. 
pod "readiness" created 
-$ 
~$ kubectl get pod readin 
STATUS RESTARTS 
Running @ 


ubuntu@k8s-master:~$ kubectl get pod readin 
NAME STATUS RESTARTS [AG 
readiness Running @ 


kubectl get pod readiness 
STATUS RESTARTS 
Running 0 





图 8-10 
Pod readiness 的 READY 状态 经 历 了 如 下 变化 : 
(1) 刚 被 创建 时 ，READY 状态 为 不 可 用 。 
(2) 15 秒 后 (initialDelaySeconds + periodSeconds) ， 第 一 次 进行 Readiness 探测 并 成 
功 返 回 ， 设置 READY 为 可 用 。 
(3) 30 秒 后 ，/tmp/healthy 被 删除 ， 连 续 3 次 Readiness 探测 均 失败 后 ，READY Ж 
设置 为 不 可 用 。 


通过 kubectl describe pod readiness 也 可 以 看 到 Readiness 探测 失败 的 日 志 , 如 图 8-11 所 示 。 














Message 


Scheduled Successfully assigned readiness to k8s-nodel 
SuccessfulMountVolume MountVolume.SetUp succeeded for volume "defoult-token-hnz7b" 
Pulling pulling image "busybox" 


Pulled Successfully pulled image "busybox" 
Created Created container 





图 8-11 
下 面 对 Liveness 探测 和 Readiness 探测 做 个 比较 : 


(1) Liveness 探测 和 Readiness 探测 是 两 种 Health Check 机 制 ， 如 果 不 特意 配置 ， 
Kubernetes 将 对 两 种 探测 采取 相同 的 默认 行为 ， 即 通过 判断 容器 启动 进程 的 返回 值 是 否 为 堆 
来 判断 探测 是 否 成 功 。 

(2) 两 种 探测 的 配置 方法 完全 一 样 ， 支 持 的 配置 参数 也 一 样 。 不 同 之 处 在 于 探测 失败 后 
的 行为 : Liveness 探测 是 重启 容器 ; Readiness 探测 则 是 将 容器 设置 为 不 可 用 , 不 接收 Service 
转发 的 请 求 。 

(3) Liveness 探测 和 Readiness 探测 是 独立 执行 的 ， 二 者 之 间 没 有 依赖 ， 所 以 可 以 单独 
使 用 , 也 可 以 同时 使 用 。 用 Liveness 探测 判断 容器 是 否 需要 重启 以 实现 自 愈 ; 用 Readiness 探 
测 判 断 容器 是 否 已 经 准备 好 对 外 提供 服务 。 








EH 
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理解 了 Liveness 探测 和 Readiness 探测 的 原理 ， 接 下 来 讨论 如 何在 业务 场景 中 使 
Health Check 








Health Check f£ Scale Up 中 的 应 用 


对 于 多 副本 应 用 ， 当 执行 Scale Up 操作 时 , 新 副本 会 作为 backend 被 添加 到 Service 的 

负载 均衡 中 ,与 已 有 副本 一 起 处 理 客户 的 请 求 。 考虑 到 应 用 启动 通常 都 需要 一 个 准备 阶段 ， 比 

如 加 载 缓 存 数据 、 连 接 数据 库 等 ， 从 容器 启动 到 真正 能 够 提供 服务 是 需要 一 段 时 间 的 。 我 们 可 

以 通过 Readiness 探测 判断 容器 是 否 就 绪 ， 避 免 将 请 求 发 送 到 还 没有 准备 好 的 backend 。 
示例 应 用 的 配置 文件 如 图 8-12 所 示 。 











apiVersion: apps/vibetal 
kind: Deployment 


replicas 
template 
metadata 
labels 
run: web 
spec 
containers 
name: web 
image: myhttpd 
ports 
containerPort 
readinessProbe 
httpGet 
scheme: HTTP 
path: /healthy 
port 
initialDelaySeconds 
periodSeconds 


apiVersion: v1 
kind: Service 
metadata 

name: web-svc 


spec 
selector 
run: web 
ports 
protocol: TCP 
port 
targetPort 





图 8-12 


重点 关注 readinessProbe 部 分 。 这 里 我 们 使 用 了 不 同 于 exec 的 另 一 种 探测 方法 httpGet。 
Kubernetes 对 于 该 方法 探测 成 功 的 判断 条 件 是 http 请 求 的 返回 代码 在 200 ~ 400 之 间 。 






































€ schema 指定 协议 ， 支 持 HTTP (RIE) fe HTTPS. 
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€ path 指定 访问 路 径 。 

@ роп 指定 端口 。 

上 面 配置 的 作用 是 : 

СТ) 容器 启动 10 秒 之 后 开始 探测 。 

(2) ШЖ http;//[container ip]:8080/healthy 返回 代码 不 是 200~400， 表 示 容 器 没有 就 绪 ， 
不 接收 Service web-svc 的 请 求 。 

(3) 每 隔 5 秒 探测 一 次 。 

(4) 直到 返回 代码 为 200~400， 表 明 容器 已 经 就 绪 ， 然 后 将 其 加 入 到 web-svc 的 负载 均 
衡 中 ， 开 始 处 理 客户 请 求 。 
(5) 探测 会 继续 以 5 秒 的 间隔 执行 ， 如 果 连 续 发 生 3 次 失败 ， 容 器 又 会 从 负载 均衡 中 
移 除 ， 直 到 下 次 探测 成 功 重新 加 入 。 


对 于 http://[container_ip]:8080/healthy， 应 用 则 可 以 实现 自己 的 判断 逻辑 ， 比 如 检查 所 依 
赖 的 数据 库 是 否 就 络 ， 示 例 代码 如 图 8-13 所 示 。 





























http.HandleFunc( , func(w http.ResponseWriter, г *http.Request) { (1 
healthy = True; 


// Check Database 
db = connect(dbIP, dbPort, dbUser, dbPassword) (2 


if db !- NULL í 
try { 
db.Query( 
} catch Се){ 
err - e.message 
$ 
} 


if db == NULL Il err != NULL í 
healthy = False 
errMsg += 


} 


if healthy { 
w.WriteC[]byteC"0k")) 

} else í 

// Send 

http.Error(w, errMsg, http.StatusServiceUnavailable) 4 


H 
Dn 


http.ListenAndServe( 





图 8-13 


@ 定义 healthy 的 处 理 函 数 。 

@ 连接 数据 库 并 执行 测试 SQL。 

© 测试 成 功 ， 正 常 返回 ， 代 码 200. 
@ 测试 失败 ， 返 回 错误 代码 503. 
© 在 8080 端口 监听 。 
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对 于 生产 环境 中 重要 的 应 用 , 都 建议 配置 Health Check, 保证 处 理 客户 请 求 的 容器 都 是 准 














备 就 绪 的 Service backend. 


Health Check 在 滚动 更 新 中 的 应 用 


Health Check 另 一 个 重要 的 应 用 场景 是 Rolling Update。 试 想 一 下 ， 现 有 一 个 了 

















E 常 运行 的 





多 副本 应 用 ， 接 下 来 对 应 用 进行 更 新 (比如 使 用 更 高 版 本 的 image? ，Kubernetes 会 启动 新 副 


本 ， 然 后 发 生 了 如 下 事件 : 








(1) 正常 情况 下 新 如 








本 需要 10 秒 钟 完成 准备 工作 ,在 





E 此 之 前 无 法 响应 业务 请 求 。 


OD 由 于 人 为 配置 错误 ， 副 本 始终 无 法 完成 准备 工作 〈 比 如 无 法 连接 后 端 数据 库 ) o 
先 别 继续 往 下 看 ， 现 在 请 花 一 分 钟 思考 这 个 问题 : 如 果 没 有 配置 Health Check, 会 出 现 怎 











样 的 情况 ? 


因为 新 副本 本 身 没 有 异常 退出 ， 默 认 的 Health Check 机 制 会 认为 容器 已 经 就 绪 ， 进 而 会 
逐步 用 新 副本 蔡 换 现 有 副本 ， 其 结果 就 是 : 当 所 有 旧 副 本 都 被 替换 后 ， 整 个 应 用 将 无 法 处 理 请 





求 ， 无 法 对 外 提供 服务 。 如 果 这 是 发 生 在 重要 的 生产 系统 上 ， 后 果 会 非常 严重 。 
新 副本 只 有 通过 了 Readiness 探测 才 会 被 添加 到 
Service; 如 果 没 有 通过 探测 ， 现 有 副本 不 会 被 全 部 替换 ， 业 务 仍然 正常 进行 。 

下 面 通过 例子 来 实践 Health Check 在 Rolling Update 中 的 应 用 。 

使 用 如 下 配置 文件 app.vl.yml 模拟 一 个 10 副本 的 应 用 ， 如 图 8-14 所 示 。 


如 果 正 确 配 置 了 Health Check, 





apiVersion: apps/vlbeta1 


kind 


Deployment 


metadata 
name: app 


spec 


replicas 
template 
metadata: 


labels 
run: app 


spec 


containers 
name: app 
image: busybox 
args: 
- /bin/sh 


-c 
- sleep 10; touch /tmp/healthy; 
readinessProbe 
exec 
command 
- cat 


- /tmp/healthy 
initialDelaySeconds: 
periodSeconds 





图 8-14 
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10 秒 后 副本 能 够 通过 Readiness 探测 ， 如 图 8-15 所 示 。 


接 下 来 滚动 更 新 应 用 ， 配 置 文件 app.v2.yml， 如 图 8-16 所 示 。 


很 显然 


LAN 


图 8-17 所 示 。 
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ubuntu&k8s-master : -$ 


ubuntuék8s-master:-$ kubectl apply -f app.vi.yml --record 


deployment "app" cre: 
ubuntuék8s-master : -$ 


ated 


ubuntuék8s-master:-$ kubectl get deployment app 
CURRENT UP-TO-DATE 


NAME DESIRED 
арр 10 
ubuntu&k8s-master: -$ 
ubuntuék8s-master:-$ 
NAME 
app-2780995820-0mpfl 
app-2780995820-9nmfm 
app-2780995820- dqdwn 
app-2780995820-g0srs 
app-2780995820-952wp 
app-2780995820-kddms 
app-2780995820-rrwsh 
app-2780995820-t3kl4 
арр-2780995820-у142п 
арр-2780995820-284х4 
ubuntu@k8s-master : ~$ 


apiVersion 


metadata 
name: app 

spec 
replicas 
template 


10 


10 


kubectl get pod 
READY STATUS 


1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 


Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 


8-15 


apps/vibetai 
kind: Deployment 


metadata 
labels 


run 
spec 


арр 


containers 


name: app 


image 


args 
/bin/sh 
с 


rea 


busybox 


пеѕ5Рг 
exec 
command 


- cat 


- /tmp/healthy 
initialDelaySeconds 
periodSeconds 


图 8-16 


AVAILABLE 


10 


RESTARTS 


ооооооооо о 





АСЕ 
285 


AGE 
325 
325 
EPI 
325 
32s 
32s 
32s 
325. 
325 
32s 





由 于 新 副本 中 不 存在 /tmp/healthy， 因 此 是 无 法 通过 Readiness 探测 的 ， 


验证 如 


ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl apply -f app ml --record 

deployment "app" configured 

ubuntuek8s-master:-$ 

ubuntu@k8s-master:~$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

app 10 13 5 8 5т 

ubuntu@k8s-master :~$ 

ubuntuek8s-master:-$ kubectl get pod 

NAME READY STATUS RESTARTS 

lapp-2780995820-0mpfl 1⁄1 Running 
1/1 Running 
1/1 Running 
1/1 Running 

арр-278099582@-ггизһ 1⁄1 Running 

lapp-2780995820-t3kl4 1/1 Running 

app-2780995820-vlqzn 1/1 Running 

lapp-27809958 1/1 Running 
0/1 Running 
0/1 Running 
0/1 Running 

Running 


eeeeeeeeeeeees 


lapp-3350497563-vh56z Running 
ubuntuek8s-master: -$ 





图 8-17 


这 个 截图 包含 了 大 量 的 信息 ， 值 得 我 们 详细 分 析 。 
先 关注 kubectl get рой 输出 : 


(1) 从 Pod 的 AGE 栏 可 判断 ， 最 后 5 个 Pod 是 新 副本 ， 目 前 处 于 NOT READY 状态 。 
(2) 旧 副 本 从 最 初 10 个 减少 到 8 个 。 


再 来 看 kubectl get deployment app 的 输出 : 


(1) DESIRED 10 表示 期 望 的 状态 是 10 个 READY 的 副本 。 

(2) CURRENT 13 表示 当前 副本 的 总 数 ， 即 8 个 旧 副 本 +5 个 新 副本 。 

(3) UP-TO-DATE 5 表示 当前 已 经 完成 更 新 的 副本 数 ， 即 5 个 新 副本 。 

(4) AVAILABLE 8 表示 当前 处 于 READY 状态 的 副本 数 ， 即 8 个 旧 副 本 。 


在 我 们 的 设 定 中 ， 新 副本 始终 都 无 法 通过 Readiness 探测 ， 所 以 这 个 状态 会 一 直 保持 下 去 。 

上 面 我 们 模拟 了 一 个 滚动 更 新 失败 的 场景 。 不 过 幸运 的 是 : Health Check 帮 有 我 们 屏蔽 了 有 
缺陷 的 副本 ， 同 时 保留 了 大 部 分 旧 副本 ， 业 务 没有 因 更 新 失败 受到 影响 。 

接 下 来 我 们 要 回答 : 为 什么 新 创建 的 副本 数 是 5 个 ， 同 时 只 销毁 了 2 个 旧 副 本 ? 

原因 是 : 滚动 更 新 通过 参数 maxSurge 和 maxUnavailable 来 控制 副本 替换 的 数量 。 





1. maxSurge 

此 参数 控制 滚动 更 新 过 程 中 副本 总 数 超过 DESIRED 的 上 限 。maxSurge 可 以 是 具体 的 整 
Ж (ш 3) ， 也 可 以 是 百 分 百 ， 向 上 取 整 。maxSurge 默认 值 为 25%. 

在 上 面 的 例子 中 ，DESIRED 为 10， 那 么 副本 总 数 的 最 大 值 为 roundUp(10 + 10 * 2596) = 
13， 所 以 我 们 看 到 CURRENT 就 是 13。 








2. maxUnavailable 
此 参数 控制 滚动 更 新 过 程 中 , 不 可 用 的 副本 相 占 DESIRED 的 最 大 比例 。maxUnavailable 
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可 以 是 具体 的 整数 〈 比 如 3) ， 也 可 以 是 百 分 百 ， 向 下 取 整 。maxUnavailable 默认 值 为 25%。 


=8, 


以 在 
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在 上 面 的 例子 中 , DESIRED 为 10, 那么 
所 以 我 们 看 到 AVAILABLE 是 8。 





可 用 的 副本 数 至 少 要 为 10 - roundDown(10* 25%) 


maxSurge 值 越 大 ， 初 始 创建 的 新 副本 数量 就 越 多 ; maxUnavailable 值 越 大 ， 初 始 销毁 的 
旧 副 本 数量 就 越 多 。 
理想 情况 下 ， 我 们 这 个 案例 滚动 更 新 的 过 程 应 该 是 这 样 的 : 





(1) 创建 3 个 新 副本 使 副本 总 数 达 到 13 个 。 
(2) 销毁 2 个 旧 副 本 使 可 用 的 副本 数 降 到 8 个 。 


(3) 


当 2 个 旧 副 本 成 功 销毁 后 ， 再 创建 2 个 新 副本 ， 使 副本 总 数 保持 为 13 个 。 


(4) 当 


(6) 旧 副 本 的 销毁 使 副本 总 数 低 了 


新 副本 通过 Readiness 探测 后 
C5) 进而 可 以 继续 销毁 更 多 的 旧 副本 ， 使 可 用 副本 数 回 
F 13， 这 样 就 允许 创建 更 多 的 新 副本 。 


会 使 可 用 副本 数 增加 ， 超 过 8。 
到 8。 





(7) 这 个 过 程 会 持续 进行 ， 最 终 所 有 的 旧 副本 都 会 被 新 副本 替换 ， A ld 





而 我 们 的 实际 情况 是 在 第 4 步 就 





ScalingReplicaSet 


ScalingReplicaSet 
ScalingReplicaSet 


Normal ScalingReplicaSet 


如 果 滚 动 更 新 失败 ， 可 以 通过 kubectl rollout undo 回 


ubuntu@k8s-master :~$ 
ubuntuék8s-master:-$ kubectl 
deployments "app" 

REVISION CHANGE-CAUSE 


kubectl apply -- 
kubectl apply 


ubuntuek8s-master :~$ 
ubuntuek8s-maste 
deployment "app 
ubuntuek8s-master: 
ubuntuék8s-master:-$ kubectl 
NAME DESIRED CURRENT 
арр 10 10 
ubuntuek8s-master:-$ 
ubuntuek8s-master:-$ 
МАМЕ 
app-2780995820-0mpfl 
app-2780995820-bq3zd 
app-2780995820-ggsrs 
app-2780995820-g52wp 
app-2780995820-kddms 
app-2780995820-mðcvr 
app-2780995820-rrwsh 
app-2780995820-t3kl4 
app-2780995820-viqzn 
app-2780995820-z8qx4 
ubuntuék8s-master:-$ 


kubectl 
led back 


kubectl 
READY 
1⁄4 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 





E kubectl describe deployment арр H H EÑ 





住 了 ， 新 副本 无 法 通过 Readiness 探测 。 这 个 过 
分 查看 ， 如 图 8-18 所 示 。 


早 可 


Message 


Scaled up replica set app-2780995820 to 10 
Scaled up replica set app-3350497563 to 3 
Scaled down replica set app-2780995820 to 8 
Scaled up replica set app-3350497563 to 5 





图 8-18 





滚 到 上 一 个 版 本 ， 如 图 8-19 所 示 。 


rollout history deployment app 


filename-app.vi.yml --record-true 
--filename-app.v2.yml --record-true 


rollout undo deployment app --to-revision-i 


get deployment app 
UP-TO-DATE AVAILABLE 
10 10 


AGE 
1h 


get pod 
STATUS 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 


ESTARTS AGE 
1h 
EI 
1h 
1h 
1h 
1m 
1h 
1h 
1h 
1h 


[4 
е 
е 
о 
е 
° 
о 
е 
е 
е 
е 


图 8-19 


如 果 要 定制 maxSurge 和 maxUnavailable， 可 以 进行 如 图 8-20 所 示 的 配置 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata 
name: app 
spec 
strategy 
rollingUpdate 
maxSurge: 35% 
maxUnavailable: 35% 
replicas 
template 
metadata 
labels 
гип: орр 
spec 


containers 


nome: app 
image: busybox 
args 
/bin/sh 
-с 
sleep 
readinessProbe 
exec 
command 
cat 
/tmp/healthy 
initialDeloySeconds 
periodSeconds 





图 8-20 


5.6 小 结 


本 章 我 们 讨论 了 Kubernetes 健康 检查 的 两 种 机 制 : Liveness 探测 和 Readiness 探测 ， 并 
实践 了 健康 检查 在 Scale Up 和 Rolling Update 场景 中 的 应 用 。 
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本 章 将 讨论 Kubernetes 如 何 管理 存储 资源 。 

首先 我 们 会 学 习 Volume, 以 及 Kubernetes 如 何 通过 Volume 为 集群 中 的 容器 提供 存储 ; 
然后 我 们 会 实践 几 种 常用 的 Volume 类 型 并 理解 它们 各 自 的 应 用 场景 最后， 我 们 会 讨论 
Kubernetes 如 何 通过 Persistent Volume 和 Persistent Volume Claim 分 离 集 群 管理 员 与 集群 用 
户 的 职责 ， 并 实践 Volume 的 静态 供给 和 动态 供给 。 


Volume 


本 节 我 们 讨论 Kubernetes 的 存储 模型 Volume, 学 习 如 何 将 各 种 持久 化 存储 映射 到 容器 。 

我 们 经 常会 说 : 容器 和 Pod 是 短暂 的 。 其 含义 是 它们 的 生命 周期 可 能 很 短 ， 会 被 频繁 
地 销毁 和 创建 。 容 器 销毁 时 ， 保 存在 容器 内 部 文件 系统 中 的 数据 都 会 被 清除 。 

为 了 持久 化 保存 容器 的 数据 ， 可 以 使 用 Kubernetes Volume。 

Volume 的 生命 周期 独立 于 容器 ,Pod 中 的 容器 可 能 被 销毁 和 重建 ,但 Volume 会 被 保留 。 

本 质 上 ，Kubernetes Volume 是 一 个 目录 , 这 一 点 与 Docker Volume 类 似 。 当 Volume 被 
mount 到 Pod, Pod 中 的 所 有 容器 都 可 以 访问 这 个 Volume。Kubernetes Volume 也 支持 多 种 
backend 类 型 ,包括 emptyDir、hostPath、GCE Persistent Disk, AWS Elastic Block Store, NFS, 
Ceph 等 , 完整 列表 可 参考 https://kubernetes.io/docs/concepts/storage/volumes/Ztypes-of-volumes 。 

Volume 提供 了 对 各 种 backend 的 抽象 ， 容 器 在 使 用 Volume 读 写 数据 的 时 候 不 需要 关 
心 数 据 到 底 是 存放 在 本 地 节点 的 文件 系统 中 还 是 云 硬 盘 上 。 对 它 来 说 , 所 有 类 型 的 Volume 都 
只 是 一 个 目录 。 


我 们 将 从 最 简单 的 emptyDir 开始 学 习 Kubernetes Volume。 





9.1.1 emptyDir 


emptyDir 是 最 基础 的 Volume 类 型 。 正 如 其 名 字 所 示 ， 一 个 emptyDir Volume 是 Host 
上 的 一 个 空 目录 。 

emptyDir Volume 对 于 容器 来 说 是 持久 的 ， 对 于 Pod 则 不 是 。 当 Pod 从 节点 删除 时 ， 
Volume 的 内 容 也 会 被 删除 。 但 如 果 只 是 容器 被 销毁 而 Pod 还 在 ， 则 Volume 不 受 影响 。 

也 就 是 说 : emptyDir Volume 的 生命 周期 与 Pod 一 致 。 











Pod 中 的 所 有 容器 都 可 以 共享 Volume， 
子 来 实践 emptyDir， 配 置 文件 如 图 9-1 所 示 。 


opiVersion: v1 
kind: Pod 
metadata 
nome 
spec 
containers 
- image: busybox 
name: producer 
volumeMounts 
- mountPath: /producer_dir 
name: shared-volume 
args 
/bin/sh 


producer-consumer 


它们 可 以 指定 各 自 的 mount 路 径 。 下 面 通过 例 


> /producer dir/hello ; sleep 


image: busybox 
name: consumer 
volumeMounts 
mountPath: /consumer dir 
name: shared-volume 
args 
/bin/sh 
-¢ 


cat /consumer_dir/hello ; sleep 


volumes 
- name: shared-volume 
emptyDir 





图 9-1 


这 里 我 们 模拟 了 一 个 producer-consumer 场景 。Pod 有 两 个 容器 producer 和 consumer， 它 
们 共享 一 个 Volume。producer 负责 往 Volume 中 写 数 据 ，consumer 则 是 从 Volume 读 取 数据 。 


© 文件 最 底部 volumes 定义 了 


-个 emptyDir 类 型 的 Volume shared-volume。 


@ producer 容器 将 shared-volume mount 到 /producer_dir 目录 。 
@) producer 通过 echo 将 数据 写 到 文件 hello Hi. 
(à) consumer 容器 将 shared-volume mount 到 /consumer dir 目录 。 


(5) consumer 通过 cat 从 文件 hello 读数 据 。 


执行 命令 创建 Pod, WE 9-2 Br. 


ubuntu@k8s-master 
ubuntuék8s-master 


pod "producer-consumer" created 


ubuntuék8s-master: 
ubuntuék8s-master 
NAME 
producer-consumer 
ubuntuék8s-master 
ubuntuék8s-master 
hello world 


READY 
2/2 
~$ 





kubectl apply -f emptyDir.yml 


~$ kubectl get pod 
STATUS 


RESTARTS 
Running @ 


AGE 
15s 


~$ kubectl logs producer-consumer consumer 


Ё 9-2 
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kubectl logs 显示 容器 consumer 成 功 读 到 了 producer 写 入 的 数据 , 验证 了 两 个 容器 共享 
emptyDir Volume。 

因为 emptyDir 是 Docker Host 文件 系统 里 的 目录 ， 其 效果 相当 于 执行 了 docker run -v 
/producer_dir 和 docker run -v /consumer dir。 通 过 docker inspect 查看 容器 的 详细 配置 信息 ， 
我 们 发 现 两 个 容器 都 mount 了 同一 个 目录 ， 如 图 9-3、 图 9-4 所 示 。 


"mounts": [ 


t 





"Source": "/var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-080027 
|4451ad/volumes/kubernetes.io-empty-dir/shared-volume", 
"Destination": "/producer dir", 


"Mode": "", 
"RW": true, 
"Propagation": "rprivate" 





图 9-3 


"Source": "/var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-080027 
|4451ad/volumes/kubernetes .io-empty-dir/shared-volume", 

"Destination": "/consumer. dir", 

"Mode": "", 

"RW": true, 

"Propagation": "rprivate" 





E 


图 9-4 


这 里 /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-0800274451ad/volumes/kubernetes. io~ 
empty-dir/shared-volume 就 是 emptyDir 在 Host 上 的 真正 路 径 。 

emptyDir 是 Host 上 创建 的 临时 目录 , 其 优点 是 能 够 方便 地 为 Pod 中 的 容器 提供 共享 存 
储 ， 不 需要 额外 的 配置 。 它 不 具备 持久 性 ， 如 果 Pod 不 存在 了 ，emptyDir 也 就 没有 了 。 根 据 
这 个 特性 ,emptyDir 特别 适合 Pod 中 的 容器 需要 临时 共享 存储 空间 的 场景 ， 比 如 前 面 的 生 
者 消费 者 用 例 。 





* 


9.1.2 hostPath 


hostPath Volume 的 作用 是 将 Docker Host 文件 系统 中 已 经 存在 的 目录 mount 给 Pod 
的 容器 。 大 部 分 应 用 都 不 会 使 用 hostPath Volume， 因 为 这 实际 上 增加 了 Роа 与 节点 的 耦合 ， 
限制 了 Pod 的 使 用 。 不 过 那些 需要 访问 Kubernetes 或 Docker 内 部 数据 (配置 文件 和 二 进 
制 库 ) 的 应 用 则 需要 使 用 hostPath。 

比如 kube-apiserver 和 kube-controller-manager 就 是 这 样 的 应 用 ， 通 过 kubectl edit 
--namespace=kube-system pod kube-apiserver-k8s-master 查看 kube-apiserver Pod 的 配置 ， 
Volume 的 相关 部 分 如 图 9-5 所 示 。 
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volumeMounts 
- mountPath: /etc/kubernetes 
name: k8s 
readOnly: 
mountPath: /etc/ssl/cents 
name: certs 
- mountPath: /etc/pki 
name: pki 
dnsPolicy: ClusterFirst 
hostNetwork 
nodeName: k8s-master 
restartPolicy: Always 
schedulerName: default-scheduler 
securityContext: {7 
terminationGracePeriodSeconds 
tolerations 
- effect: NoExecute 
operator: Exists 
volumes 
- hostPath 
path: /etc/kubernetes 
name: k8s 
hostPath 
path: /etc/ssl/certs 
name: certs 
hostPath: 
path: /etc/pki 
name: pki 





图 9-5 
这 里 定义 了 三 个 hostPath: volume k8s. certs 和 pki， 分 别 对 应 Host 目录 /etc/kubemetes、 
/etc/ssl/certs 和 /etc/pki。 
如 果 Pod 被 销毁 了 ，hostPath 对 应 的 目录 还 是 会 被 保留 ， 从 这 一 点 来 看 ，hostPath 的 持 
久 性 比 emptyDir 强 。 不 过 一 旦 Host Hit, hostPath 也 就 无 法 访问 了 。 
接 下 来 我 们 将 学 习 具 备 真 正 持久 性 的 Volume. 


9.1.3 外 部 Storage Provider 


如 果 Kubernetes 部 署 在 诸如 AWS, GCE. Azure 等 公有 云 上 ， 可 以 直接 使 用 云 硬盘 作 
为 Volume。 下 面 给 出 一 个 AWS Elastic Block Store 的 例子 ， 如 图 9-6 所 示 。 
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apiVersion: vl 
kind: Pod 
metadata: 

name: using-ebs 

spec 

containers: 

- image: busybox 
name: using-ebs 
volumeMounts : 

- mountPath: /test-ebs 
name: ebs-volume 
volumes 

- name: ebs-volume 


awsElasticBlockStore 
volumeID: <volume-id> 
fsType: ext4 





Eg 9-6 
要 在 Pod 中 使 用 ESB volume， 必 须 先 在 AWS 中 创建 ， 然 后 通过 volume-id 引用 。 其 
他 云 硬盘 的 使 用 方法 可 参考 各 公有 云 厂 商 的 官方 文档 。 
Kubernetes Volume 也 可 以 使 用 主流 的 分 布 式 存储 ， 比 如 Ceph、GlusterFS 等 。 下 面 给 出 
-个 Ceph 的 例子 ， 如 图 9-7 所 示 。 











apiVersion: v1 
kind: Pod 
metadata: 
name: using-ceph 
spec: 
containers 
- image: busybox 
name: using-ceph 
volumeMounts: 


- name: ceph-volume 
mountPath: /test-ceph 
VOLumes : 


- name: ceph-volume 
cephfs 
path: /some/path/in/side/cephfs 
monitors: 
secretFile: 





图 9-7 


Ceph 文件 系统 的 /some/path/in/side/cephfs 目录 被 mount 到 容器 路 径 /test-ceph。 

相对 于 emptyDir 和 hostPath， 这 些 Volume 类 型 的 最 大 特点 就 是 不 依赖 Kubernetes。 
Volume 的 底层 基础 设施 由 独立 的 存储 系统 管理 ， 与 Kubernetes 集群 是 分 离 的 。 数 据 被 持久 
化 后 ， 即 使 整个 Kubernetes 崩溃 也 不 会 受 损 。 

当然 , 运 维 这 样 的 存储 系统 通常 不 是 一 项 简单 的 工作 , 特别 是 对 可 靠 性 、 可 用 性 和 扩展 性 
有 较 高 要 求 的 时 候 。 
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PersistentVolume & PersistentVolumeClaim 


Volume 提供 了 非常 好 的 数据 持久 化 方案 ， 不 过 在 可 管理 性 上 还 有 不 足 。 








拿 前 面 的 AWS EBS 例子 来 说 ， 要 使 用 Volume, Pod 必须 事先 知道 如 下 信息 : 








(1) 当前 Volume 来 自 AWS EBS。 
(2) EBS Volume 已 经 提前 创建 ， 并 且 知道 确切 的 volume-id。 














Pod 通常 是 由 应 用 的 开发 人 员 维 护 ， 而 Volume 则 通常 是 由 存储 系统 的 管理 员 维 护 。 开 














发 人 员 要 获得 上 面 的 信息 ， 要 么 询问 管理 员 ， 要 么 自己 就 是 管理 员 。 





这 样 就 带 来 一 个 管理 上 的 问题 : 应 用 开发 人 员 和 系统 管理 员 的 职责 耦合 在 一 起 了 。 如 果 系 





统 规 横 较 小 或 者 对 于 开发 环境 ， 这 样 的 情况 还 可 以 接受 ， 当 集群 规模 变 大 ， 特 昂 
境 ， 考 虑 到 效率 和 安全 性 ， 这 就 成 了 必须 要 解决 的 问题 。 
Kubernetes 给 出 的 解决 方案 是 PersistentVolume 和 PersistentVolumeClaim 
PersistentVolume (РУ) 是 外 部 存储 系统 中 的 一 块 存储 空间 ， 由 管理 员 凶 
Volume 一 样 ，PV 具有 持久 性 ， 生 命 周 期 独立 于 Pod。 
PersistentVolumeClaim (PVC) 是 对 PV 的 申请 (Claim) 。PVC 通常 





o 


аж 





363 
H 











和 维护 。 需 要 为 Роа 分 配 存 储 资源 时 ， 用 户 可 以 创建 一 个 PVC， 指 明 存 储 资源 前 


和 访问 横 式 〈 比 如 只 读 ) 等 信息 ，Kubernetes 会 查找 并 提供 满足 条 件 的 PV。 


于 生成 环 


维护 。 与 


用 户 创建 
容量 大 小 


有 了 PersistentVolumeClaim， 用 户 只 需要 告诉 Kubernetes 需要 什么 样 的 存储 资源 ， 而 不 
必 关 心 真正 的 空间 从 哪里 分 配 、 如 何 访问 等 底层 细节 信息 。 这 些 Storage Provider 的 





交 给 管理 员 来 处 理 ， 只 有 管理 员 才 应 该 关心 创建 PersistentVolume 的 细节 信息 





底层 信息 


Kubernetes 支持 多 种 类 型 的 PersistentVolume， 比 如 AWS EBS、Ceph、NFS 等 ,完整 列 


表 请 参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes o 


下 面 我 们 用 NFS 来 体会 PersistentVolume 的 使 用 方法 。 


9.2.1 NFS PersistentVolume 


作为 准备 工作 , 我 们 已 经 在 k8s-master 节点 上 搭建 了 一 个 NFS 服务 器 ,目录 为 /nfsdata, 


如 图 9-8 所 示 。 


root@k8s-master:~# 
root@k8s-master:~# showmount -e 


Export list for k8s-master: 
/nfsdata * 





图 9-8 
下 面 创建 一 个 PV mypv1， 配 置 文件 nfs-pvl.yml 如 图 9-9 所 示 。 
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apiVersion: vl 
kind: PersistentVolume 
metadata 
name: mypv1 
Spec: 
capacity: 
storage: 161 


accessModes 

- ReodWriteOnce 
persistentVolumeReclaimPolicy: Recycle 
storageClassName: nfs 
nfs 

path: /nfsdata/pv1 

server: 192.168.56.105 





图 9-9 


@) capacity 指定 PV 的 容量 为 1GB 。 

Q) accessModes 指定 访问 模式 为 ReadWriteOnce, 支持 的 访问 模式 有 3 种 :ReadWriteOnce 
表示 РУ 能 以 read-write 模式 mount 到 单个 节点 ，ReadOnlyMany 表示 PV 能 以 read-only 
模式 mount 到 多 个 节点 , ReadWriteMany 表示 PV 能 以 read-write 模式 mount 到 多 个 节点 。 

(3) persistentVolumeReclaimPolicy 指定 当 PV 的 回收 策略 为 Recycle， 支 持 的 策略 有 3 fb: 
Retain 表示 需要 管理 员 手 工 回收 ;Recycle 表示 清除 PV 中 的 数据 ， 效 果 相 当 于 执行 rm -rf 
Ahevolume/*; Delete 表示 删除 Storage Provider 上 的 对 应 存储 资源 ,例如 AWS EBS.GCE PD. 
Azure Disk、OpenStack Cinder Volume 等 。 

@ storageClassName 指定 PV 的 class 为 п. 相当 于 为 PV 设置 了 一 个 分 类 , РУС 可 
以 指定 class 申请 相应 class 的 PV。 

© 指定 PV 在 NFS 服务 器 上 对 应 的 目录 。 


创建 mypv1， 如 图 9-10 所 示 。 


ubuntu@k8s-master:~$ 

ubuntuék8s-master:-$ kubectl apply -f nfs-pv1.yml 
persistentvolume "mypvi" created 
ubuntuek8s-master:-$ 




















ubuntuék8s-master:-$ kubectl get pv 

NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE 
туру1 161 RWO Recycle Avoilable nfs 15s 
ubuntuek8s-master:-$ 





图 9-10 


STATUS Jj Available, #7: mypvl й, "ЫЖ РУС 申请 。 
接 下 来 创建 PVC mypvc1， 配 置 文件 nfs-pvcl.yml 如 图 9-11 所 示 。 
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kind: PersistentVolumeClaim 
apiVersion: vl 
metadata: 
name: турус1 
spec: 
accessModes: 


- ReadWriteOnce 
resources: 
requests: 
storage: 161 
storageClassName: nfs 





图 9-11 


PVC 就 很 简单 了 ， 只 需要 指定 PV 的 容量 、 访 问 模式 和 class 即 可 。 
创建 mypvc1， 如 图 9-12 所 示 。 


ubuntuêk8s-master :~$ 
ubuntuék8s-master:-$ kubectl apply -f nfs-pvci.yml 
persistentvolumeclaim "mypvci" created 
$ 
$ kubectl get pvc 
STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
Bound mypv1 161 RWO nfs 22s 


CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE 
туру1 161 RWO Recycle Bound default/mypvc1| nfs 6m 
ubuntu@k8s-master:~$ 





图 9-12 


从 kubectl get pvc 和 kubectl get pv 的 输出 可 以 看 到 mypvcl 已 经 Bound 到 mypv1， 申 请 成 
功 。 
接 下 来 就 可 以 在 Pod 中 使 用 存储 了 ，Pod 配置 文件 podl.yml 如 图 9-13 所 示 。 


kind: Pod 
apiVersion: v1 
metadata 
name: mypod1 
spec 
containers 
- name; mypodi 
image: busybox 
args 
- /bin/sh 
=€ 
- sleep 
volumeMounts 
mountPath 
name: mydata 


- name; mydata 
persistentVolumeClaim 
claimName: mypvc1 





图 9-13 
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与 使 用 普通 Volume 的 格式 类 似 ， 在 volumes 中 通过 persistentVolumeCI 
mypvcl 申请 的 Volume。 
创建 mypod1， 如 图 9-14 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f podi.yml 
pod "туроа1" created 
ubuntuék8s master: -$ 


ubuntuék8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
туроа1 1⁄1 Running 0 32s 10.244.4.60 — k8s-no 
ubuntuek8s master :-$ 





图 9-14 


验证 PV 是 否 可 用 ， 如 图 9-15 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl exec mypod1 touch /mydata/hello 
ubuntuék8s-master:-$ 

ubuntuek8s-master:-$ 15 /nfsdata/pvi/ 

hello 

ubuntuék8s-master:-$ 


图 9-15 


可 见 ， 在 Pod 中 创建 的 文件 /mydata/hello 确实 已 经 保存 到 了 NFS 
/nfsdata/pvl 中 。 


9.2.2 回收 PV 
当 不 需要 使 用 PV 时 ， 可 用 删除 PVC 回收 PV， 如 图 9-16 所 示 。 


ubuntu@k8s-master 
ubuntu@k8s-master kubectl delete pvc турус1 
persistentvolumeclaim "турус1" deleted 
ubuntuék8s-master 
ubuntuék8s-master:-$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS АСЕ IP. 
pod1 1⁄1 Running 9 10.244.4.60 





9/1 ContainerCreating 0 <none> 
ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get ру 

МАМЕ CAPACITY ACCESSMODES — RECLAIMPOLICY STORAGE 
туру1 161 RWO Recycle default/mypvci nfs 
ubuntu@k8s-master:~$ 


图 9-16 








aim 指定 使 用 











del 





服务 器 目录 


NODE 
k8s-node1 
k8s-node1 


CLASS REA 


当 PVC турус1 被 删除 后 , 我 们 发 现 Kubernetes 启动 了 一 个 新 Pod recycler-for-mypvl, 这 
个 Pod 的 作用 就 是 清除 PV mypvl 的 数据 。 此 时 туру1 的 状态 为 Released， 表 示 已 经 解除 了 


与 mypvcl 的 Bound， 正 在 清除 数据 ， 不 过 此 时 还 不 可 用 。 




















当 数 据 清除 完毕 , mypvl 的 状态 重新 变 为 Available, 此 时 可 以 被 新 的 PVC H 
所 示 。 
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His, 如 图 9-17 





lubuntu@k8s-master 


CAPACITY ACCESSMODES 


RWO 


RECLAIMPOLICY 
Recycle 


:~$ 1s /nfsdata/pv1/ 


图 9-17 


/nfsdata/pv1 中 的 hello 文件 已 经 被 删除 了 。 


因为 PV 的 








如 果 我 们 希望 保留 数据 ， 可 以 将 策略 设置 为 Retain， 





apiVersion: v1 
kind: PersistentVolume 
metadata 
name 
spec 
capacity 
storage 
accessModes 
-_ReadWrite0nce 
е stentVolumeR 
storageClassName 
nfs 
path 
server 


mypv1 


161 


nfs 


/nfsdata/pvi 
192.168.56.105 


图 9-18 


通过 kubectlapply 更 新 PV， 如 图 9-19 所 示 。 


jubuntuek8s -master:-$ 

lubuntuék8s-master:-$ kubectl apply -f nfs-pvi.yml 
persistentvolume " configured 

iubuntuék8s -maste 

ubuntuek8s-maste 


CAPACITY ACCESSMODES 


图 9-19 








= 








ubuntu@k8s-master : ~$ 

ubuntuek8s-master:-$ kubectl apply -f nfs-pvci.yml 
persistentvolumeclaim "mypvc1" created 
ubuntu@k8s-master:~$ 


aimPolic 





CLAIM 


如 图 9-18 所 示 。 


Retain 


STATUS 
Available 


CLAIM 





ubuntuek8s-master: 
ubuntuek8s-maste 
ubuntuek8s-master: 


persistentvolumecl 
ubuntuék8s-maste. 
ubuntuek8s-maste 
NAME САРАСТТҮ 
туру1 16i 
ubuntuék8s-master: 
ubuntuek8s-maste. 
МАМЕ READY 
mypod1 1⁄4 


kubectl exec mypod1 touch /mydata/hello 
-$ 
$ ls /nfsdata/pv1/ 


kubectl delete pvc mypvc1 
aim "mypvc1" deleted 
-$ 
kubectl get pv 
ACCESSMODES RECLAIMPOLICY 
RWO Retain 
-$ 


CLAIM 


:-$ kubectl get pod -o wide 


STATUS 
Running @ 


RESTARTS AGE IP 
46m 10.244.4.60 


NODE 
k8s-nodei 


ubuntuek8s-master:-$ 


ubuntuek8s-maste 
hello 
ubuntuek8s-master: 


$ 15 /nfsdata/pv1/ 


= 


图 9-20 


default/mypvci 


STORAGECLASS 
nfs 


STORAGECLASS 
nfs 


收 策略 已 经 变 为 Retain， 通 过 下 面 的 步骤 验证 其 效果 ， 如 图 9-20 所 示 。 


STORAGECLASS 
nfs 





回收 策略 设置 为 Recycle, 所 以 数据 会 被 清除 , 但 这 可 能 不 是 我 们 想 要 的 结果 。 
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© 重新 创建 mypvcl. 

Q) 在 mypvl 中 创建 文件 hello. 

© mypvl 状态 变 为 Released。 

@ Kubernetes 并 没有 启动 Pod recycler-for-mypv1 o 
© PV 中 的 数据 被 完整 保留 。 


虽然 mypvl 中 的 数据 得 到 了 保留 ， 但 其 РУ 状态 会 一 直 处 于 Released， 不 能 被 其 他 
PVC 申请 。 为 了 重新 使 用 存储 资源 ， 可 以 删除 并 重新 创建 mypv1。 删 除 操作 只 是 删除 了 РУ 
对 象 ， 存 储 空间 中 的 数据 并 不 会 被 删除 。 

新 建 的 mypvl 状态 为 Available， 如 图 9-21 所 示 ， 已 经 可 以 被 PVC 申请 。 


DEN 

















-$ kubectl delete pv mypvi 
persistentvolume "туру1" deleted 
ubuntuek8s-mastei 
lubuntuékBs-master:-$ kubectl apply -f nfs-pvi.yml 


persistentvolume "mypvi" created 

ubuntuek8s-mastei 

ubuntuek8s-master:-$ kubectl get pv 

МАМЕ CAPACITY ACCESSMODES RECLAIMPOLICY [5 CLAIM STORAGECLASS REASON АСЕ 
Imypv1 16i RWO Retain nfs 95 
ubuntuêk8s-master :~$ 





Ё 9-21 


PV 还 支持 Delete 的 回收 策略 ， 会 删除 PV 在 Storage Provider 上 对 应 的 存储 空间 。NFS 的 
PV 不 支持 Delete, 支持 Delete 的 Provider 有 AWS EBS.GCE РР”. Azure Disk, OpenStack Cinder 


Volume 等 。 





9.2.3 PV 动态 供给 


在 前 面 的 例子 中 ， 我 们 提前 创建 了 PV， 然 后 通过 PVC 申请 PV 并 在 Pod 中 使 用 ， 这 
种 方式 叫 作 静态 供给 (Static Provision) o 

与 之 对 应 的 是 动态 供给 (Dynamical Provision) ， 即 如 果 没 有 满足 PVC fH PV, 会 
动态 创建 PV。 相 比 静 态 供给 ， 动 态 供给 有 明显 的 优势 :不 需要 提前 创建 PV， 减 少 了 管理 员 
的 工作 量 ， 效 率 高 。 

动态 供给 是 通过 StorageClass 实现 的 ，StorageClass 定义 了 如 何 创建 PV， 下 面 给 出 两 个 
例子 。 


(1) StorageClass standard， 如 图 9-22 所 示 。 





kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 

name: standard 


provisioner: kubernetes.io/aws-ebs 
parameters: 

type: gp2 
reclaimPolicy: Retain 





图 9-22 
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(2) StorageClass slow， 如 图 9-23 所 示 。 


kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 

name: slow 


provisioner: kubernetes.io/aws-ebs 
parameters: 
type: 101 
zones: us-east-1d, us-east-1c 
iopsPerGB: 





图 9-23 


这 两 个 StorageClass 都 会 动态 创建 AWS EBS， 不 同 点 在 于 standard 创建 的 是 gp2 类 型 
的 EBS, 而 slow 创建 的 是 iol 类 型 的 ЕВЅ. 不 同类 型 的 EBS 支持 的 参数 可 参考 AWS Tr 
方 文档 。 
StorageClass 支持 Delete 和 Retain 两 种 reclaimPolicy， 默 认 是 Delete, 
与 之 前 一 样 ，PVC 在 申请 PV 时 ， 只 需要 指定 StorageClass、 容 量 以 及 访问 模式 即 可 ， 
如 图 9-24 所 示 。 
kind: PersistentVolumeClaim 
apiVersion: vl 
metadata: 
name: турус1 


spec 
accessModes 


- ReadWriteOnce 


resources: 
requests 


storage: 1Gi 
图 9-24 
除了 AWS EBS，Kubernetes 还 支持 其 他 多 种 动态 供给 PV 的 Provisioner， 完 整 列 表 请 参 


Ж; https;//kubernetes.io/docs/concepts/storage/storage-classes/Zprovisioner. 





一 个 数据 库 例子 


本 节 演 示 如 何 为 MySQL 数据 库 提 供 持 久 化 存储 ， 步 骤 为 : 

(1) 创建 PV 和 PVC. 

(2) 部 署 MySQL。 

(3) 向 MySQL 添加 数据 。 

(4) 模拟 节点 宕 机 故障 ，Kubernetes 将 MySQL 自动 迁移 到 其 他 节点 。 
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(5) 验证 数据 一 致 性 。 
首先 创建 PV 和 PVC， 配 置 说 明 如 下 。 


€  mysql-pv.yml 如 图 9-25 所 示 。 
€  mysql-pvc.yml 如 图 9-26 所 示 。 


apiVersion: vl 


Баа артиста kind: PersistentVolumeClaim 


metadata 
name: mysql-pv 
spec: 
accessModes 
- ReadWriteOnce 


capacity 


storage: 161 


persistentVolumeReclaimPolicy 
storageClassNome: nfs 


nfs 


path: /nfsdata/mysql-pv 
192.168.56.105 


server 





v1 


apiVersion 
metadata: 
mysql-pvc 


name 
spec 
accessModes : 
- ReadWrite0nce 
resources 
requests: 
storage: 1Gi 
storageClassName: nfs 


Retain 





图 9-25 图 9-26 


创建 mysql-pv 和 mysqlL-pvc， 如 图 9-27 所 示 。 


ubuntuek8s-master 
ubuntuek8s-master 
persistentvolume 

ubuntuék8s-master 
ubuntuek8s-master 


E: 
=$ kubectl apply -f mysql-pv.yml 
mysql-pv" created 
~$ 
kubectl apply -f mysql-pvc.yml 


persistentvolumeclaim "mysql-pvc" created 
ubuntuek8s-master 


ubuntuék8s-master:-$ kubectl get pv,pvc 


CLAIM 
default/mysql-pve 


МАМЕ 
pv/mysql-pv 


CAPACITY 
16i 


ACCESSMODES 
RWO 


RECLAIMPOLICY 
Retain 


STATUS 
Bound 


NAME STATUS 
pvc/mysql-pvc Воипа 
ubuntu@k8s-master:~$ 


VOLUME 
mysql-pv 


CAPACITY 
1Gi 


ACCESSMODES 
RWO 


STORAGECLASS 
nfs 


AGE 
9s 





图 9-27 


接 下 来 部 署 MySQL， 配 置 文件 如 图 9-28 所 示 。 
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apiVersion: v1 
kind: Service 
metadata 
name 
spec 
ports 
port 
selector 
app: mysql 


mysql 


apiVersion: apps/vibetai 
kind: Deployment 
metadata 
name: mysql 
spec: 
selector 
matchLabels 
app: mysql 
template 
metadata 
labels 
app 
spec 
containers 
- image: mysql:5.6 
name: mysql 
env 
name 
value 
ports: 
- containerPort 
name: mysql 
volumeMounts : 
name: mysql-persistent-storage 
mountPath: /var/lib/mysql 
volumes: 
- name: mysql-persistent-storage 
persistentVolumeClaim: 
claimName: mysql-pvc 


mysql 


MYSQL_ROOT_PASSWORD 
password 


图 9-28 





PVC mysql-pvc Bound 的 PV mysql-pv 将 被 mount 到 MySQL 的 数据 目录 var/lib/mysql, 如 


图 9-29 所 示 。 


ubuntuék8s-master: ~$ 

ubuntu&k8s-master:-$ kubectl apply -f mysql.yml 
service "mysql" created 

deployment "mysql" created 

ubuntuék8s-master:-$ 
ubuntuék8s-maste 
NAME 
mysqL-2150355289-p99h8 
ubuntuék8s-master:-$ 


kubectl get pod -o wide 


READY 
1/1 


STATUS RESTARTS 
Running 0 


AGE 
15s 


图 9-29 





IP NODE 
10.244.5.80 — k8s-node2 


MySQL 被 部 署 到 k8s-node2， 下 面 通过 客户 端 访问 Service mysql, ЩІ 9-30 所 示 。 


kubectl run -it --rm --image-mysql:5.6 --restart-Never mysql-client -- mysql 


-h mysql -ppassword 
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ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ kubectl run -it --rm --image-mysql:5.6 --restart-Never mysql-client -- mysql -h mysql -ppassword 


If you don't see a command prompt, try pressing enter. 


mysql» 
图 9-30 
更 新 数据 库 ， 如 图 9-31 所 示 。 


mysql> 
mysql> use mysql 

Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 
Database changed 

mysql> create table my id( id int(4) ); 

Query OK, 0 rows affected (0.01 sec) 


mysql» insert my id values( 111 ); 
Query OK, 1 row affected (0.00 sec) 


mysql» select * from my. id; 


1 row in set (0.00 sec) 
mysql> 
图 9-31 
@) 切换 到 数据 库 mysql。 
@ 创建 数据 库 表 my id. 
@ 插入 一 条 数据 。 
@ 确认 数据 已 经 写 入 。 


关闭 k8s-node2， 模 拟 节 点 宕 机 故障 ， 如 图 9-32 所 示 。 


Connection to 192.168.56.107 closed by remote host. 
Connection to 192.168.56.107 closed. 





图 9-32 


ubuntuék8s-master:-$ kubectl get pod -o wide 


NAME READY STATUS RESTARTS AGE IP 
mysql-2150355289-p13n5 1/1 Running 0 31s 10.244.4.66 
mysqL-2150355289-p99h8 1/1 Unknown @ 16m 10.244.5.80 
ubuntuék8s-master:-$ 





图 9-33 


验证 数据 的 一 致 性 ， 如 图 9-34 所 示 。 








NODE 
k8s-node1 
k8s-node2 


ubuntu@k8s-master:-$ 
ubuntu@k8s-master:~$ kubectl run -it --rm --image=mysql:5.6 --restart-Never mysql-client -- mysql -h mysql -ppassword 
If you don't see a command prompt, try pressing enter. 


mysql> use mysql 
Reading table information for completion of table and column names 
You сап turn off this feature to get а quicker startup with -A 


Database changed 
mysql> select * from my id; 


1 row in set (0.00 sec) 





mysql» 
图 9-34 
MySQL 服务 恢复 ， 数 据 也 完好 无 损 。 


小 结 


本 章 我 们 讨论 了 Kubernetes 如 何 管 理 存 储 资源 。 

emptyDir 和 hostPath 类 型 的 Volume 很 方便 ， 但 可 持久 性 不 强 ，Kubernetes 支持 多 种 
外 部 存储 系统 的 Volume。 

PV 和 PVC 分 离 了 管理 员 和 普通 用 户 的 职责 ， 更 适合 生产 环境 。 我 们 还 学 习 了 如 何 通过 
StorageClass 实现 更 高 效 的 动态 供给 。 

最 后 ， 我 们 演示 了 如 何在 MySQL 中 使 用 PersistentVolume 实现 数据 持久 性 。 
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第 10 = 
Secret & Configmap 


应 用 启动 过 程 中 可 能 需要 一 些 敏感 信息 ， 比 如 访问 数据 库 的 用 户 名 、 密 码 或 者 密 钥 。 将 这 
息 直 接 保存 在 容器 镜像 中 显然 不 受 ，Kubernetes 提供 的 解决 方案 是 Secret. 

Secret. 会 以 密 文 的 方式 存储 数据 ， 避 免 了 直接 在 配置 文件 中 保存 敏感 信息 。Secret 会 以 
Volume 的 形式 被 mount 到 Pod， 容 器 可 通过 文件 的 方式 使 用 Secret 中 的 敏感 数据 ;此 外 ， 
容器 也 可 以 环境 变量 的 方式 使 用 这 些 数据 。 

Secret 可 通过 命令 行 或 YAML 创建 ,比如 希望 Secret 中 包含 如 下 信息 :用 户 名 admin ~ 
密码 123456。 
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创建 Secret 
有 四 种 方法 创建 Secret: 


(1) 通过 --from-literal: 
kubectl create secret generic mysecret --from-literal-username-admin 
--from-literal-password-123456 


每 个 --from-literal 对 应 一 个 信息 条 目 。 


(2) 通过 --from-file: 
echo -n admin > ./username 
echo -n 123456 » ./password 


kubectl create secret generic mysecret --from-file-./username 
--from-file-./password 


每 个 文件 内 容 对 应 一 个 信息 条 目 。 





(3) 通过 --from-env-file: 
cat << EOF > env.txt 
username-admin 
password-123456 
EOF 


kubectl create secret generic mysecret --from-env-file-env.txt 


文件 env.txt 中 每 行 Key=Value 对 应 一 个 信息 条 目 。 
(4) 通过 YAML 配置 文件 ， 如 图 10-1 所 示 。 


apiVersion: vi 
kind: Secret 
metadata 

name: mysecret 


data 
username: YWRtoW4= 
password: MTIzNDU2 





图 10-1 
文件 中 的 敏感 数据 必须 是 通过 base64 编码 后 的 结果 ， 如 图 10-2 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ echo -n admin | base64 
YWRtaW4= 

ubuntu@k8s-master:~$ echo -n 123456 | base64 
MTIzNDU2 

ubuntuek8s master: -$ 





图 10-2 


执行 kubectl apply 创建 Secret, ШЖ 10-3 所 示 。 


ubuntuêk8s-master ERE 

ubuntuek8s-master:-$ kubectl apply -f mysecrete.yml 
secret "mysecret" created 

ubuntuék8s-master: ~$ 





图 10-3 


ТҮРЕ 
0paque 
ubuntuek8s-master:-$ 





图 10-4 


显示 有 两 个 数据 条 目 ， 通 过 kubectl describe secret 查看 条 目的 Key， 如 图 10-5 所 示 。 
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ubuntuek8s-master:-~$ 

ubuntuék8s-master:-$ kubectl describe secret mysecret 
Мате: mysecret 

Namespace: default 

Labels: <none> 

Annotations: <none> 


Opaque 





图 10-5 


如 果 还 想 查看 Value， 可 以 用 kubectl edit secret mysecret， 如 图 10-6 所 示 。 


apiVersion: vi 
data 
password: MTIzNDU2 
username: YWRtaW4= 
kind: Secret 
metadata 
creationTimestamp: 2017-10-10T07:16:21Z 
name: mysecret 
namespace: default 
resourceVersion 
selfLink: /api/v1/namespaces/default/secrets/mysecret 
uid: eaeb4980-ad8a-11e7-8f72-0800274451ad 
type: Opaque 





图 10-6 
然后 通过 base64 将 Value 反 编 码 ， 如 图 10-7 所 示 。 


ubuntuek8s-master 
ubuntuék8s-master:-$ echo -n MTIzNDU2 | base64 --decode 
123456ubuntuék8s-master :~$ 


ubuntuék8s-master:-$ echo -n YWRtoW4- | base64 --decode 
adminubuntuék8s-master:-$ 
ubuntuék8s-master:-$ 





图 10-7 


j f£ Pod 中 使 用 Secret 


Pod 可 以 通过 Volume 或 者 环境 变量 的 方式 使 用 Secret. 


10.3.1 Volume 方式 
Pod 的 配置 文件 如 图 10-8 所 示 。 


(D) 定义 volume foo， 来 源 为 secret mysecret。 
Q) 将 foo mount 到 容器 路 径 /etc/foo， 可 指定 读 写 权 限 为 readOnly。 
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创建 Pod 并 在 容器 中 读 取 Secret， 如 图 10-9 所 示 。 


apiVersion: vl 
kind: Pod 
metadata 

name: mypod 


spec 
containers 
- name: mypod ubuntuék8s-master:-$ kubectl apply -f mypod.yml 
pod "mypod" created 
ubuntuék8s-master:-$ 
ubuntuek8s-master:-$ kubectl exec -it mypod sh 


image: busybox 
args 
- /bin/sh 
-c 
- sleep 10; touch /tmp/healthy; sleep /# 
volumeMounts / # 1s /etc/foo 
name: foo password username 
mountPath /# 
read0nly / # cat /etc/foo/username 
volumes £ admin/ # 
лаке roo / # cat /etc/foo/password 


secret 
secretName: mysecret REL si 


图 10-8 图 10-9 


可 以 看 到 ，Kubernetes 会 在 指定 的 路 径 /etc/foo 下 为 每 条 敏感 数据 创建 一 个 文件 ， 文 件 
名 就 是 数据 条 目的 Key， 这 里 是 /etc/foo/username 和 /etc/foo/password, Value 则 以 明文 存放 
在 文件 中 。 

我 们 也 可 以 自 定义 存放 数据 的 文件 名 ， 比 如 将 配置 文件 改 为 如 图 10-10 所 示 那 样 。 


apiVersion: vl 
kind: Pod 
metadata 
пате: mypod 
spec 
containers 
name: mypod 
image: busybox 





- sleep 10; touch /tmp/healthy; sleep 
volumeMounts 
name: foo 
mountPath 
readOnly 
volumes 
- name: foo 
secret 
secretName: mysecret 
Ttems 
- key: username 
path: my-group/my-username 
Кеу: password 
path: my-group/my-password 





图 10-10 


这 时 数据 将 分 别 存 放 在 /etc/foo/my-group/my-usemame 和 /etc/foo/my-group/my-password 中 。 
以 Volume 方式 使 用 的 Secret 支持 动态 更 新 : Secret 更 新 后 ， 容 器 中 的 数据 也 会 更 新 。 
将 password 更 新 为 abcdef，base64 编码 为 YWJjZGVm， 如 图 10-11 所 示 。 
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更 新 Secret， 如 图 10-12 所 示 。 


apiVersion: v1 
kind: Secret 
metadata 

name; mysecret 


data ubuntu@k8s-master:~$ 
username; YWRtaW4= ubuntu@k8s-master:~$ kubectl apply -f mysecrete.yml 


password: YWJjZGVm Secret "mysecret" configured 


ubuntuek8s-master:-$ 





Р 10-11 10-12 
ЛЖ, BI) password 会 同步 到 容器 ， 如 图 10-13 所 示 。 


/# 

/ € cat /etc/foo/password 
123456/ # 

/# 

/ # cat /etc/foo/password 
abcdef/ # 

/ # 





Р 10-13 


10.32 ”环境 变量 方式 

通过 Volume 使 用 Secret， 容 器 必须 从 文件 读 取 数据 ， 稍 显 麻 烦 ，Kubernetes 还 支持 通 
过 环境 变量 使 用 Secret。 

Pod 配置 文件 示例 如 图 10-14 所 示 。 





apiVersion: vl 
kind: Pod 
metadata 
name: mypod 
spec 
containers 
name: mypod 
image: busybox 
args 
/bin/sh 
-c 
sleep 10; touch /tmp/healthy; sleep 


name: SECRET. USERNAME 
valueFrom 
secretKeyRef 
name: mysecret 
key: username 
name: SECRET_PASSWORD 
valueFrom 
secretKeyRef 
name: mysecret 
key: password 





图 10-14 


创建 Pod 并 读 取 Secret, Ш 10-15 所 示 。 
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ubuntuék8s-master :~$ 


kubectl apply -f mypod-env.yml 


pod "mypod" created 

ubuntuék8s-master :~$ 

ubuntuék8s-master:-$ kubectl exec -it mypod sh 
/# 

/ # echo SSECRET. USERNAME 

admin 

/# 

/ # echo $SECRET_PASSWORD 





图 10-15 


通过 环境 变量 SECRET USERNAME 和 SECRET PASSWORD 成 功 读 取 到 Secret 的 
数据 。 
需要 注意 的 是 ， 环 境 变 量 读 取 Secret 很 方便 ， 但 无 法 支撑 Secret 动态 更 新 。 


ConfigMap 


Secret 可 以 为 Pod 提供 密码 、Token、 私 钥 等 敏感 数据 ; 对 于 一 些 非 敏感 数据 ， 比 如 应 
用 的 配置 信息 ， 则 可 以 用 ConfigMap。 

ConfigMap 的 创建 和 使 用 方式 与 Secret 非常 类 似 ， 主 要 的 不 同 是 数据 以 明文 的 形式 存 
放 。 

与 Secret 一 样 ，ConfigMap 也 支持 四 种 创建 方式 : 


(1) 通过 --from-literal: 
kubectl create configmap myconfigmap --from-literal-configl-xxx 
--from-literal-config2-yyy 


每 个 --from-literal 对 应 一 个 信息 条 目 。 
(2) 通过 --from-file: 


echo -n ххх > ./configl 

echo -n ууу > ./config2 

kubectl create configmap myconfigmap --from-file-./configl 
--from-file-./config2 


每 个 文件 内 容 对 应 一 个 信息 条 目 。 


(3) 通过 --from-env-file: 
cat << EOF > env.txt 
configl-xxx 
config2-yyy 
EOF 
kubectl create configmap myconfigmap --from-env-file-env.txt 
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文件 env.txt 中 每 行 Key=Value 对 应 一 个 信息 条 目 。 

(4) 通过 YAML 配置 文件 ， 如 图 10-16 所 示 。 文 件 中 的 数据 直接 以 明文 输入 。 
与 Secret 一 样 ，Pod 也 可 以 通过 Volume 或 者 环境 变量 的 方式 使 用 Secret。 

(1) Volume 方式 如 图 10-17 所 示 。 


apiVersion: vl 
кїпа: Pod 
metadata 
name: mypod 
spec 
containers 
name: mypod 
image: busybox 
args 
- /bin/sh 
-=Ç 
- sleep 10; touch /tmp/healthy; sleep 
volumeMounts 
name: foo 
mountPath: 
readOnl 
volumes 
nome: foo 
configMap 
name: myconfigmap 


apiVersion: vl 
kind: ConfigMap 
metadata 
name: myconfigmap 
data 
configl: xxx 
config2: yyy 





图 10-16 图 10-17 
(2) 环境 变量 方式 如 图 10-18 所 示 。 


apiVersion: vi 
kind: Pod 
metadata 
name: mypod 
spec 
containers 
name: mypod 
image: busybox 
args 
/bin/sh 


10; touch /tmp/healthy; sleep 


name: CONFIG 1 
valueFrom 
configMapKeyRef 
name: myconfigmap 
key: config1 
name: CONFIG_2 
valueFrom 
configMapKeyRef 
name: myconfigmap 
key: config2 





El 10-18 








大 多 数 情况 下 ， 配 置信 息 都 以 文件 形式 提供 ， 所 以 在 创建 ConfigMap 时 通常 采用 
--from-file 或 YAML 方式 ， 读 取 ConfigMap 时 通常 采用 Volume 方式 。 比 如 给 Pod 传递 
如 何 记录 日 志 的 配置 信息 ， 如 图 10-19 所 示 。 








class: logging.handlers.RotatingFileHandler 
formatter: precise 


level: INFO 
filename: %hostname-%timestamp.log 





图 10-19 
可 以 采用 --from-file 形式 ， 将 其 保存 在 文件 logging.conf 中 ， 然 后 执行 命令 : 
kubectl create configmap myconfigmap --from-file-./logging.conf 
如 果 采 用 YAML 配置 文件 ， 其 内 容 则 如 图 10-20 所 示 。 


apiVersion: v1 
kind: ConfigMap 
metadata 
name: myconfigmap 
data: 
logging.conf: | 
class: logging.handlers.RotatingFileHandler 
formatter: precise 
level: INFO 
filename: Xhostname-Xtimestamp.log 





图 10-20 


注意 ， 别 漏 写 了 Key logging.conf 后 面 的 | 符号 。 
创建 并 查看 ConfigMap， 如 图 10-21 所 示 。 


ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl apply -f myconfigmap.yml 
configmap "myconfigmap" created 

ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get configmap myconfigmap 

NAME DATA AGE 

myconfigmap 1 12s 

ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl describe configmap myconfigmap 
Nane: myconfigmap 

Nanespace: default 

Labels: <none> 

Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion" :"v1"| 
e-Xtimestamp... 


Logging. conf: 


class: logging.handlers.RotatingFileHandler 
formatter: precise 

level: INFO 

filename: Xhostname-Xtimestomp.log 


Events: «none» 
ubuntuék8s-master:-$ 





图 10221 
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在 Pod 中 使 用 此 ConfigMap， 配 置 文件 如 图 10-22 所 示 。 


apiVersion: vl 
kind: Pod 
metadata 


containers: 
name: mypod 
image: busybox 
args 
- /bin/sh 
"ue 
- sleep 10; touch /tmp/healthy; sleep 
volumeMounts 
name: foo 
mountPath 
volumes 
name: foo 
configMap 
name: myconfigmap 
items 
- key: logging.conf 
path: myapp/logging. conf 





10-22 


(D 在 volume 中 指定 存放 配置 信息 的 文件 相对 路 径 为 myapp/logging.conf。 
Q) 将 volume mount. 到 容器 的 /etc 目录 。 
创建 Pod 并 读 取 配 置信 息 ， 如 图 10-23 所 示 。 


ubuntuek8s-master:-$ 

ubuntuGk8s-master:-$ kubectl apply -f mypod.yml 
pod "mypod" created 

ubuntuek8s-master: ~$ 

ubuntuek8s-master:-$ kubectl exec -it mypod sh 
/ # 





/ # cat /etc/myapp/logging.conf 

class: logging.handlers.RotatingFileHandler 
formatter: precise 

level: INFO 

filename: 9Xhostname-Xtimestamp.log 

/ # 





图 10-23 


配置 信息 已 经 保存 到 /ete/myapp/logging.conf 文件 中 。 与 Secret 一 样 ，Volume 形式 的 
ConfigMap 也 支持 动态 更 新 ， 留 给 大 家 自己 实践 。 


小 结 


本 章 我 们 学 习 了 如 何 向 Pod 传递 配置 信息 。 如 果 信 息 需 要 加 密 ， 可 使 用 Secret; 如 果 是 
一 般 的 配置 信息 ， 则 可 使 用 ConfigMap. 

Secret 和 ConfigMap 支持 四 种 定义 方法 。Pod 在 使 用 它们 时 , 可 以 选择 Volume 方式 或 
环境 变量 方式 ， 不 过 只 有 Volume 方式 支持 动态 更 新 。 
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= 11 = 


Kubernetes 
的 已 管 理 器 





Helm 


本 章 我 们 将 学 习 Helm 一 一 Kubernetes 的 包 管理 器 。 

每 个 成 功 的 软件 平台 都 有 一 个 优秀 的 打包 系统 ， 比 如 Debian、Ubuntu 的 apt，Red Hat、 
CentOS 的 yum。Helm 则 是 Kubernetes 上 的 包 管理 器 。 

本 章 我 们 将 讨论 为 什么 需要 Helm、 它 的 架构 和 组 件 ， 以 及 如 何 使 用 Helm. 


Why Helm 


Helm 到 底 解 决 了 什么 问题 ?为 什么 Kubernetes 需要 Helm? 
答案 是 : Kubernetes 能 够 很 好 地 组 织 和 编排 容器 ， 但 它 缺 少 一 个 更 高 层次 的 应 用 打包 工 
R, Hü Helm 就 是 来 干 这 件 事 的 。 
先 来 看 个 例子 。 
比如 对 于 一 个 MySQL 服务 ， Kubernetes 需要 部 署 下 面 这 些 对 象 : 
(1) Service， 让 外 界 能 够 访问 到 MySQL， 如 图 11-1 所 示 。 
apiVersion: vl 
kind: Service 
metadata: 
name: my-mysql 
labels: 


app: my-mysql 
spec: 


ports: 
- name: mysql 

port: 

targetPort: mysql 
selector: 


app: my-mysql 





图 11-1 


(2) Secret， 定 义 MySQL 的 密码 ， 如 图 11-2 所 示 。 
(3) PersistentVolumeClaim， 为 MySQL 申请 持久 化 存储 空间 ， 如 图 11-3 所 示 。 





kind: PersistentVolumeClaim 
apiVersion: vi 
metadata 
name: my-mysql 
labels 
app: my-mysql 


аріМегѕіоп: v1 
kind: Secret 
metadata 
name: my-mysql 
labels 


app: my-mysql 
type: Opaque 
data: 
mysql-root-password 
mysql-password 


spec 
accessModes 
resources 
requests 
storage 





E 11-2 图 11-3 
(4) Deployment, й MySQL Pod， 并 使 用 上 面 的 这 些 支 持 对 象 ， 如 图 11-4 所 示 。 


apiVersion: extensions/vlbetal 
kind: Deployment 
metadata 
name: my-mysql 
labels 
app: my-mysql 
spec 
template 
metadata 
labels 
app: my-mysql 
spec 
containers 
name: my-mysql 
image 
env 
- name: MYSQL_ROOT_PASSWORD 
valueFrom 
secretKeyRef: 
name: my-mysql 
key: mysql-root-password 
name: MYSQL. PASSWORD 
valueFrom 
secretKeyRef 
name: my-mysql 
key: mysql-password 
name: MYSQL USER 
value 
name: MYSQL. DATABASE 
value 
ports 
- name: mysql 
containerPort: 
volumeMounts 
пате: data 
mountPath: /var/lib/mysql 
volumes 
- name: data 
persistentVolumeClaim 
claimName: my-mysql 





E 11-4 
我 们 可 以 将 上 面 这 些 配置 保存 到 对 象 各 自 的 文件 中 , 或 者 集中 写 进 一 个 配置 文件 , 然后 通 
过 kubectl apply -f 部 署 。 
到 目前 为 止 ，Kubermetes 对 服务 的 部 署 支 持 得 都 挺 好 ， 如 果 应 用 只 由 一 个 或 几 个 这 样 的 
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服务 组 成 ， 上 面 的 部 署 方式 完全 足够 了 。 
但 是 , 如 果 我 们 开发 的 是 微服 务 架 构 的 应 用 , 组 成 应 用 的 服务 可 能 多 达 十 个 甚至 几 十 上 百 
个 ， 这 种 组 织 和 管理 应 用 的 方式 就 不 好 使 了 : 


CD 很 难 管理 、 编 辑 和 维护 如 此 多 的 服务 。 每 个 服务 都 有 若干 配置 ， 缺 乏 一 个 更 高 层次 
的 工具 将 这 些 配 置 组 织 起 来 。 

(2) 不 容易 将 这 些 服务 作为 一 个 整体 统一 发 布 。 部 署 人 员 需 要 首先 理解 应 用 都 包含 哪些 
服务 , 然后 按照 逻辑 顺序 依次 执行 kubectl apply， 即 缺少 一 种 工具 来 定义 应 用 与 服务 ， 以 及 服 
务 与 服务 之 间 的 依赖 关系 。 

G) 不 能 高 效 地 共享 和 重用 服务 。 比 如 两 个 应 用 都 要 用 到 MySQL 服务 ， 但 配置 的 参数 
不 一 样 ， 这 两 个 应 用 只 能 分 别 复 制 一 套 标 准 的 MySQL. 配置 文件 ， 修 改 后 通过 kubectl apply 
部 署 。 也 就 是 说 ， 不 支持 参数 化 配置 和 多 环境 部 署 。 

(4) 不 支持 应 用 级 别 的 版 本 管理 。 虽 然 可 以 通过 kubectl rollout undo 进行 回 滚 ， 但 这 只 
能 针对 单个 Deployment， 不 支持 整个 应 用 的 回 滚 。 

(5) 不 支持 对 部 署 的 应 用 状态 进行 验证 。 比 如 是 否 能 通过 预定 义 的 账号 访问 MySQL. 
虽然 Kubernetes 有 健康 检查 , 但 那 是 针对 单个 容器 ,我 们 需要 应 用 (服务 ) 级 别 的 健康 检查 。 


Helm 能 够 解决 上 面 这 些 问题 ,Helm 帮助 Kubernetes 成 为 微服 务 架构 应 用 理想 的 部 署 平台 。 























Helm 架构 


在 实践 之 前 ， 我 们 先 来 看 看 Helm 的 架构 。 
Helm 有 两 个 重要 的 概念 : chart 和 release。 





€ chart 是 创建 一 个 应 用 的 信息 集合 ， 包 括 各 种 Kubernetes 对 象 的 配置 模板 、 参 数 定 
义 、 依 赖 关 系 、 文 档 说 明 等 。chart 是 应 用 部 署 的 自 包含 逻辑 单元 。 可 以 将 chart Ж 
象 成 apt yum 中 的 软件 安装 包 。 

€ release 是 chart 的 运行 实例 ， 代 表 了 一 个 正在 运行 的 应 用 。 当 chart 被 安装 到 
Kubernetes 集群 ,就 生成 一 个 releases chart 能 够 多 次 安装 到 同一 个 集群 ， 每 次 安装 
都 是 一 个 release。 


Helm 是 包 管理 工具 ， 这 里 的 包 就 是 指 的 chart, Helm 能 够 : 


e 从容 创建 新 chart, 

€ 与 存储 chat 的 仓库 交互 ， 拉 取 、 保 存 和 更 新 chart. 
€ 在 Kubernetes 集群 中 安装 和 却 载 release. 

ө 更 新 、 回 滚 和 测试 release。 


Helm 包含 两 个 组 件 : Helm 客户 端 和 Tiller 服务 器 ， 如 图 11-5 所 示 。 
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Helm | ERPC == 


Kubernetes 





图 11-5 
Helm 客户 端 是 终端 用 户 使 用 的 命令 行 工具 ， 用 户 可 以 : 
在 本 地 开发 chart。 
管理 chart 仓库 。 
与 Tiller 服务 器 交互 。 
在 远程 Kubernetes 集群 上 安装 chart。 
查看 release 信息 。 
升级 或 却 载 已 有 的 release; 
Tiller 服务 器 运行 在 Kubernetes 集群 中 ， 它 会 处 理 Helm 客户 端的 请 求 ， 与 Kubernetes 
API Server 交互 。Tiller 服务 器 负责 : 
© 监听 来 自 Helm 客户 端的 请 求 。 
€ 通过 chat 构建 release。 
€ 在 Kubernetes 中 安装 chart， 并 跟踪 release 的 状态 。 
€ 通过 API Server 升级 或 卸载 已 有 的 releases 


简单 地 讲 ，Helm 客户 端 负责 管理 chart，Tiller 服务 器 负责 管理 release。 


本 节 我 们 将 依次 安装 Helm 客户 端 和 Tiller 服务 器 。 


11.3.1 Helm 客户 端 
通常 ， 我 们 将 Helm 客户 端 安装 在 能 够 执行 kubectl 命令 的 节点 上 ， 只 需要 下 面 一 条 命令 : 
curl https://raw.githubusercontent .com/kubernetes/helm/master/scripts/get | bash 


结果 如 图 11-6 所 示 。 


ubuntuek8s-master:-$ 
ubuntuék8s-master:-$ curl https://row.githubusercontent.com/kubernetes/helm/master/scripts/get | bash 
X Total Ж Received X Xferd Average Speed Time Time Time Current 
Dlood Upload Total Spent f ed 
100 6329 100 6329 о ә 4179 9 0:00:01 0:00:01 - 180 





Downloading https://kubernetes-heln.storage.googleapis.com/helm-v; -linux-and64.tar.gz 
Preparing to install into /usr/local/bin 
helm installed into /usr/local/bin/helm 


Run 'helm init' to configure helm. 
ubuntuék8s-master:-$ 





图 11-6 
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执行 helm version 验证 ， 如 图 11-7 所 示 。 


ubuntuek8s-master:-$ helm version 
Client: &version.Version[SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636 


i49775617287cc26e53dba4", GitTreeState:"clean"] 
Error: cannot connect to Tiller 
ubuntuek8s master :~$ 





图 11-7 
目前 只 能 查看 到 客户 端的 版 本 ， 服 务 器 还 没有 安装 。 
helm 有 很 多 子 命令 和 参数 , 为 了 提高 使 用 命令 行 的 效率 , 通常 建议 安装 helm 的 bash fy 
令 补 全 脚本 ， 方 法 如 下 : 


helm completion bash > .helmrc echo "source .helmrc" >> .bashrc 





completion get 1 repo status version 
create history lint reset template 

delete home list rollback test 

dependency init package search upgrade 

fetch inspect plugin serve verify 
ubuntu@k8s-master:~$ helm install -- 

--name- --tls-ca-cert- 
namespace- --tls-cert- 
name-template- --tls-key- 
no-hooks --tls-verify 

place --values- 
--verify 
--version- 
tiller-namespace- --wait 
timeout- 
--kube-context- = 
ubuntu@k8s-master:~$ 





图 11-8 


11.3.2 Tiller 服务 器 
Tiller 服务 器 安装 非常 简单 ， 只 需要 执行 helm init 即 可 ， 如 图 11-9 所 示 。 


ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ helm init 
$HELM HOME has been configured at /home/ubuntu/.helm. 


Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. 
Happy Helming! 
ubuntuek8s-nmaster:-$ 





图 11-9 
Tiller 本 身 也 是 作为 容器 化 应 用 运行 在 Kubernetes Cluster 中 的 ， 如 图 11-10 所 示 。 
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ubuntuek8s-maste! 


:~$ kubectl get --nomespace-kube-system svc tiller-deploy 
CLUSTER-IP EXTERNAL-IP РОКТСЅ) AGE 
tiller-deploy 10.98.124.71 <none> 44134/TCP 1m 
ubuntuék8s-master:-$ 
:-$ kubectl get --namespace-kube-system deployment tiller-deploy 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
1 


tiller-deploy 1 1 1 
ubuntuék8s-maste 

ubuntuekSs-master:-$ kubectl get --namespace-kube-system pod tiller-deploy-1936853538-c8sfp 
НАМЕ READY STATUS RESTARTS AGE 
tiller-deploy-1936853538-c8sfp 1⁄1 Running 0 2n 

ubuntuék8s-master:-$ 


1m 





图 11-10 


可 以 看 到 Tiller 的 Service. Deployment 和 Pod. 
现在 ，helm version 已 经 能 够 查看 到 服务 器 的 版 本 信息 了 ， 如 图 11-11 所 示 。 


rootek8s-master:- helm version 

Client: &version.Version[SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636d9775617287cc 
26e53dba4", GitTreeState:"clean") 

Server: &version.Version([SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636d9775617287cc 
26e53dba4", GitTreeState:"clean"] 





图 11-11 


使 用 Helm 


Helm 安装 成 功 后 ， 可 执行 helm search. 查看 当前 可 安装 的 chart， 如 图 11-12 所 示 。 


ubuntuek8s-master 

ubuntuek8s-master:~$ helm search 

NAME ERSION DESCRIPTION 

local/cool-chart A Helm chart for Kubernetes 
stable/acs-engine-autoscaler Scales worker nodes within agent pools 
stable/artifactory Universal Repository Manager supporting all maj... 
stable/aws-cluster-autoscaler Scales worker nodes within autoscaling groups. 
stable/buildkite Agent for Buildkite 

stable/centrifugo Centrifugo is a reol-time messaging server. 
stable/chaoskube Chaoskube periodically kills random pods in you. 
stable/chronograf Open-source web application written in Go and R. 


stable/cockroachdb 
stable/concourse 
stable/consul 
stable/coredns 
stable/coscale 
stable/dask-distributed 
stable/datadog DataDog Agent 

stable/dokuwiki š DokuWiki is a standards-compliant, simple to us. 
stable/drupal .10.2 One of the most versatile open source content m 
stable/etcd-operator ‚5. CoreOS etcd-operator Helm chart for Kubernetes 


CockroachDB is a scalable, survivable, strongly.. 
Concourse is a simple and scalable CI system. 
Highly available and distributed service discov. 
CoreDNS is a DNS server that chains middleware . 
CoScale Agent 

Distributed computation in Python 


Ii 
0 
0 
9 
1 
L] 
D 
o 
EN 
stable/cluster-autoscaler .2.0 Scales worker nodes within autoscaling groups. 
0 
D 
2 
D 
D 
o 
о 
D 





图 11-12 


这 个 列表 很 长 ， 这 里 只 截取 了 一 部 分 。 大 家 不 禁 会 问 ， 这 些 chart 都 是 从 哪 上 





ЕЖ? 


前 面 说 过 ，Helm 可 以 像 apt 和 ушт 管理 软件 包 一 样 管理 chart。apt 和 ушп 的 软件 包 


存放 在 仓库 中 ， 同 样 的 ，Helm 也 有 仓库 ， 如 图 11-13 所 示 。 
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ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ helm repo 115+ 
NAME URL 


stable https://kubernetes-charts.storage.googleapis.com 
1оса1 http://127.0.0.1:8879/charts 
ubuntuék8s-master:-$ 


图 11-13 





Helm 安装 时 已 经 默认 配置 好 了 两 个 仓库 : stable 和 local. stable 是 官方 仓库 ，local 是 

















户 存放 自己 开发 的 chart 的 本 地 仓库 。 








helm search 会 显示 chart 位 于 哪个 仓库 ， 比 如 local/cool-chart 和 stable/acs-engine- 


autoscaler。 


用 户 可 以 通过 helm repo add. 添加 更 多 的 仓库 ， 比 如 企业 的 私有 仓库 ， 仓 库 的 管理 和 维护 


方法 请 参考 官网 文档 https://docs.helm.sh。 


与 apt 和 yum 一 样 ,helm 也 支持 关键 字 搜索 , 如 图 11-14 所 示 。 包 括 DESCRIPTION fE 





内 的 所 有 信息 ， 只 要 跟 关 键 字 匹配 ， 都 会 显示 在 结果 列表 中 。 


ubuntuék8s-moster:-$ 

ubuntu@k8s-master:-$ helm search mysql 

NAME VERSION DESCRIPTION 
stable/mysql 0.3.0 Fast, reliable, scalable, ond easy to use open 


stoble/percona free, fully compatible, enhanced, open source 


stable/gcloud-sqlproxy Google Cloud SQL Proxy 


stable/mariadb 2.0.0 Fast, reliable, scalable, and easy to use open-... 





lubuntuek8s-master:-$ 


图 11-14 


安装 chart 也 很 简单 ， 执 行 如 下 命令 就 可 以 安装 MySQL. 


helm install stable/mysql 


如 果 看 到 如 图 11-15 所 示 的 报错 ， 通 常 是 因为 Tiller 服务 器 的 权限 不 足 。 


ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ helm install stable/mysql 


Error: no available release name found 
ubuntuek8s-master :-$ 





图 11-15 
执行 如 下 命名 添加 权限 : 


kubectl create serviceaccount --namespace kube-system tiller 

kubectl create clusterrolebinding tiller-cluster-rule 
--clusterrole-cluster-admin --serviceaccount-kube-system:tiller 

kubectl patch deploy --namespace kube-system tiller-deploy -p 
'("spec": ("template": ("spec":("serviceAccount":"tiller"]]])' 


然后 再 次 执行 下 面 的 命令 ， 结 果 如 图 11-16 所 示 。 


helm install stable/mysql 


t 
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ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm install stable/mysql 
NAME: fun-zorse 

LAST DEPLOYED: Тие Oct 17 11:34:55 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Service 

NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
fun-zorse-mysql 10.108.23.5 «none» 3306/ТСР 9s 
==> vlbetal/Deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
fun-zorse-mysql 1 1 1 о 

==> vi/Secret 

МАМЕ TYPE DATA AGE 

fun-zorse-mysql Opaque 2 15 

==> v1/PersistentVolumeClaim 


NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
fun-zorse-mysql Pending 1s 


БШ con be accessed via port 3306 on the following DNS name from within your cluster: 
fun-zorse-mysql . default .svc.cluster.local 
To get your root password run: 

kubectl get secret --nomespace default fun-zorse-mysql -o jsonpath-"[.dota.mysql-root-passwori 
To connect to your database: 
1. Run an Ubuntu pod that you can use as a client: 

kubectl run -i --tty ubuntu --image-ubuntu:16.04 --restart-Never -- bash -il 


Instoll the mysql client: 


$ apt-get update && apt-get install mysql-client -y 


. Connect using the mysql cli, then provide your password: 
$ mysql -h fun-zorse-mysql -p 





图 11-16 
输出 分 为 三 部 分 : 
(D chart. 本 次 部 署 的 描述 信息 。 


€ NAME X release 的 名 字 ， 因 为 我 们 没 用 -n 参数 指定 ， 所 以 Нет 随机 生成 了 一 
个 ， 这 里 是 fun-zorse。 

© NAMESPACE X release 部 署 的 namespace ， 默 认 是 default， 也 可 以 通过 
--namespace 指定 。 

€ STATUS 为 DEPLOYED， 表 示 已 经 将 chart 部 署 到 集群 。 


©) 当前 release 包含 的 资源 : Service. Deployment, Secret 和 PersistentVolumeClaim， 


其 名 字 都 是 fun-zorse-mysql， 命 名 的 格式 为 ReleasName-ChartName。 


@ NOTES 部 分 显示 的 是 release 的 使 用 方法 ， 比 如 如 何 访问 Service、 如 何 获取 数据 库 





密码 以 及 如 何 连 接 数据 库 等 。 
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通过 kubectl get 可 以 查看 组 成 release 的 各 个 对 象 ， 如 图 11-17 所 示 。 


ubuntuék8s-master:-$ 


ubuntuek8s-master:-$ kubectl get service fun-zorse-mysql 


NAME 
fun-zorse-mysql 
ubuntuék8s-master 


CLUSTER-IP 


10.108.23.5 <none> 


EXTERNAL-IP 


PORT(S) AGE 
3306/TCP 15m 


ubuntu@k8s-master:~$ kubectl get deployment fun-zorse-mysql 


NAME DESIRED CURRENT 


fun-zorse-mysql 1 1 1 
ubuntu@k8s-master:~$ 


UP-TO-DATE 


AVAILABLE AGE 
9 15m 


ubuntuék8s-master:-$ kubectl get pod fun-zorse-mysql-2959529493-hfqlt 


NAME 
fun-zorse-mysql-2959529493-hfg1t 0/1 
ubuntuek8s-master:-$ 


READY 


STATUS RESTARTS AGE 
Pending 0 15m 


ubuntuék8s-master:-$ kubectl get pvc fun-zorse-mysql 


NAME STATUS 
fun-zorse-mysql Pending 
ubuntuék8s-master:-$ 


VOLUME 


CAPACITY 





ACCESSMODES — STORAGECLASS AGE 


15m 


图 11-17 


因为 我 们 还 没有 准备 PersistentVolume， 所 以 当前 release 还 不 可 用 。 
helm list 显示 已 经 部 署 的 release，helm delete 可 以 删除 release， 如 图 11-18 所 示 。 


ubuntuëk8s-master: 
ubuntu@k8s-mastei 
NAME Ri 
fun-zorse n 


helm list 


ISION UPDATED 


ubuntuek8s-master:-$ 


ubuntuék8s-master:-$ helm delete fun-zorse 
release "fun-zor: deleted 
ubuntuek8s-master:~$ 


Tue Oct 17 11:34:55 2017 





STATUS 
DEPLOYED 


CHART 
mysql-0.3.0 


NAMESPAQ 
default 


图 11-18 
Helm 的 使 用 方法 像 极 了 apt 和 yum, H Helm 来 管理 Kubernetes 应 用 非常 方便 。 


|. chart 详解 











chart 是 Helm 的 应 用 打包 格式 。chart 








-系列 文件 组 成 ， 这 些 文件 描述 了 Kubernetes 


部 署 应 用 时 所 需要 的 资源 ， 比 如 Service, Deployment, PersistentVolumeClaim、 Secret. 


ConfigMap 等 。 














单个 的 chart 可 以 非常 简单 ， 只 用 于 部 署 一 个 服务 ， 比 如 Memcached。chart 也 可 以 很 复 





杂 ， 部 署 整 个 应 用 ， 比 如 包含 HTTP Servers, 


Database、 消 息 中 间 件 、Cache 等 。 


chart 将 这 些 文件 放置 在 预定 义 的 目录 结构 中 ， 通 常 整个 chart 被 打 成 tar 包 ， 而 且 标 注 





上 版 本 信息 ， 便 于 Helm 部 署 。 


下 面 我 们 将 详细 讨论 chart 的 目录 结构 以 及 包含 的 各 类 文件 。 


11.5.1 chart 目录 结构 


以 前 面 MySQL chart 为 例 。 
中 找到 chart 的 tar 包 ， 如 图 11-19 所 示 。 


- 且 安 装 了 某 个 chart， 我 们 就 可 以 在 —/.helm/cache/archive 
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ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ ls ~/.helm/cache/archive 


mysql-0.3.0.tgz 
ubuntuék8s-master:-$ 





B 11-19 


解压 后 ，MySQL chart 目录 结构 如 图 11-20 所 示 。 


ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ tree mysql 
mysql 

I— Chart.yaml 

F— README. md 

I— templates 

l I— configmap.yaml 
| I— deployment .yaml 
I К— .helpers.tpl 

I H- NOTES.txt 

| I— pvc.yaml 

| secrets.yaml 

I L— svc.yaml 

-— values.yaml 


1 directory, 10 files 
ubuntu@k8s-master:~$ 





图 11-20 
目录 名 就 是 chart 的 名 字 不 带 版 本 信息 ) ， 这 里 是 mysql， 包 含 如 下 内 容 。 


(1) Chart.yaml 
YAML 文件 ， 描 述 chart 的 概要 信息 ， 如 图 11-21 所 示 。 


description: Fast, reliable, scalable, and easy to use open-source relational database 
system. 

engine: gotpl 

home: https://www.mysql.com/ 

icon: https://ww.mysql.com/common/logos/logo-mysql-170x115.png 

keywords 

- mysql 
database 
sql 


maintainers 
email: viglesias@google. com 
name: Vic Iglesias 

name: mysql 

sources 


- https://github.com/kubernetes/charts 
https://github.com/docker-library/mysql 
version: 0.3.0 





图 11221 
name 和 version 是 必 填 项 ， 其 他 都 是 可 选项 。 


(2) README.md 


Markdown 格式 的 README 文件 , 相当 于 chart 的 使 用 文档 , 此 文件 为 可 选 , 如 图 11-22 
所 示 。 
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) is one of the most popular database servers in the world. Notable users includi 


This chart bootstraps a single node MySQL deployment on a [Kub є ) cluster usin| 


Kubernetes 1.6+ with Beta APIs enabled 
PV provisioner support in the underlying infrastructure 


t 


To install the chart with the release name ‘my-release 


$ helm install --name my-release stoble/mysql 


The command deploys MySQL on the Kubernetes cluster in the defoult configuration. The [co 1 


By default a random password will be generated for the root user. If you'd like to set your own password 
in the values.yaml. 


You can retrieve your root password by running the following command. Make sure to replace [YOURBRELEASER| 


printf $Cprintf 'NXo' ^kubectl get secret [YOUR RELEASE NAME]-mysql -o jsonpath-"[.data.mysql-root-pa 
тр: List all releases using `helm list 


To uninstall/delete the 'my-release' deployment: 
$ helm delete my-release 


The command removes all the Kubernetes components associated with the chart and deletes the release. 


The following tables lists the configurable parameters of the MySQL chart and their default values. 


Parameter Description Default 


1 
fs 
1 "imageTag 

| "imagePullPolicy 
| "mysqlRootPassword 
I 
1 
1 


1 
(t: 
mysql' image tag 1 Most recent release 

Image pull policy 1 "IfNotPresent 
Password for the 'root' user. 1 nil 
Username of new user to create. | `nil 
Password for the new user. 1 `nil 

1 


Name for new database to create. nil 


mysqlUser 
mysqlPassword 


1 
1 
1 
1 
1 
1 
1 
mysqlDatabase 1 





图 11-22 


(3) LICENSE 
文本 文件 ， 描 述 chart 的 许可 信息 ， 此 文件 为 可 选 。 


(4) requirements.yaml 


chart 可 能 依赖 其 他 的 chart， 这 些 依赖 关系 可 通过 requirements.yaml 指定 ， 如 图 11-23 
所 示 。 


dependencies 
- name: rabbitmq 
version: 1.2.3 
repository: http://example.com/charts 


name: memcached 
version: 3.2.1 
repository: http://another.example.com/charts 





图 1123 
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在 安装 过 程 中 ， 依 赖 的 chart 也 会 被 一 起 安装 。 


(5) values.yaml 
chart 支持 在 安装 时 根据 参数 进行 定制 化 配置 ， 而 values.yaml 则 提供 了 这 些 配置 参数 的 
默认 值 ， 如 图 11-24 所 示 。 








## mysql image version 
image: "mysql" 
imageTag: "5.7.14" 


## Specify password for root user 

## 

## Default: random 10 character string 
# mysqlRootPassword: testing 


## Create a database user 
## 

# mysqlUser: 

# mysqlPassword: 


imagePullPolicy: IfNotPresent 


## Persist data to a persitent volume 

persistence: 
enabled: true 
## If defined, storageClassName: «storageClass» 
#0 If set to "-", storageClassName: "", which disables dynamic provisioning 
## 
# storageClass: "- 
accessMode: ReadWriteOnce 
size: 861 


## Configure resource requests and limits 
## 
resources: 
request 
memory: 256Mi 
cpu: 100m 


4 Custom mysql configuration files used to override default mysql settings 
configurationFiles: 

# mysql.cnf: l- 

# [mysqld] 

# skip-name-resolve 





图 1124 


(6) templates 目录 

各 类 Kubernetes 资源 的 配置 模板 都 放置 在 这 里 。Helm 会 将 values.yaml 中 的 参数 值 注 
入 模板 中 ， 生 成 标准 的 YAML 配置 文件 。 

模板 是 chart 最 重要 的 部 分 ， 也 是 Helm 最 强大 的 地 方 。 模 板 增加 了 应 用 部 署 的 灵活 性 ， 
能 够 适用 不 同 的 环境 ， 我 们 后 面 会 详细 讨论 。 
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(7) templates/NOTES.txt 
chart 的 简易 使 用 文档 ，chart 安装 成 功 后 会 显示 此 文档 内 容 ， 如 图 11-25 所 示 。 


MySQL can be accessed via port 3306 on the following DNS name from within your cluster: 
{{ template "mysql.fullname" . }}.{{ .Release.Namespace ]].svc.cluster.local 


To get your root password run: 
kubectl get secret --namespace ff .Release.Namespace }} (í template "mysql.fullname" 
connect to your database: 

. Run an Ubuntu pod that you con use as a client: 
kubectl run -i --tty ubuntu --image-ubuntu:16.04 --restart-Never -- bash -il 

. Install the mysql client: 
$ apt-get update && apt-get install mysql-client -y 


. Connect using the mysql cli, then provide your password: 
$ mysql -h {{ template "mysql.fullname" . }} -p 





图 11-25 
与 模板 一 样 ， 可 以 在 NOTE.txt 中 插入 配置 参数 ，Helm 会 动态 注入 参数 值 。 


11.5.2 chart 模板 


Helm 通过 模板 创建 Kubernetes 能 够 理解 的 YAML 格式 的 资源 配置 文件 ， 我 们 将 通过 
例子 来 学 习 如 何 使 用 模板 。 
以 templates/secrets.yaml 为 例 ， 如 图 11-26 所 示 。 


opiVersion: v1 
kind: Secret 
metadata 
name { template 
labels 
арр: {{ template 
сһаг+: 
release 
heritage 
type: 0paque 
data 
if .Values.mysqlRootPassword }} ) 
mysql-root-password [í .Values.mysqlRootPassword | b64enc | quote } 
else 
mysql-root-password í randAlphaNum I b64enc | quote 
end | 
if .Values.mysqlPassword 
mysql-password: {{ .Values.mysqlPassword | b64enc | quote 
else 
mysql-password: {{ randAlphaNum 1 b64enc 1 quote 
í end } 





图 11-26 


从 结构 上 看 ， 文 件 的 内 容 非常 像 Secret 配置 ， 只 是 大 部 分 属性 值 变 成 了 {{ ххх }}。 这 些 
{{ ххх }} 实际 上 是 模板 的 语法 。Helm 采用 了 Go 语言 的 模板 来 编写 chart. Со 模板 非常 强 
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大 ， 支 持 变量 、 对 象 、 函 数 、 流 控制 等 功能 。 下 面 我 们 通过 解析 templates/secrets.yaml 快速 


学 习 模板 。 


(D {{ template "mysql.fullname" . }} 定义 Secret 的 name。 关 键 字 template ЙЕН 
日 一 个 子 模 板 mysql.fullname。 这 个 子 模板 是 在 templates/_helpers.tpl 文件 中 定义 的 ， 如 图 

















-27 所 示 。 














{{/* vim: set filetypeemustache: */}} 
{{/* 
Expand the name of the chart 


„УА 


} 


{{- define "mysql.name" -}} 
{{- default .Chart.Name .Values.name0verride | trunc 63 | trimSuffix "-" -}} 
[f- end -}} 


{{/* 
Create a default fully qualified app name. 


We 
D 


truncate at 63 chars because some Kubernetes name fields аге limited to this 


define "mysql.fullname 
default .Ch lame .Values.nameOverride -}} 
lease.Name $name | trunc 63 | trimSuffix 





图 11-27 


是 引 


这 个 定义 还 是 很 复杂 的 ， 因 为 它 用 到 了 模板 语言 中 的 对 象 、 函 数 、 流 控制 等 概念 。 现 在 看 
不 懂 没 关系 ， 这 里 我 们 学 习 的 重点 是 : 如 果 存 在 一 些 信息 多 个 模板 都 会 用 到 ， 则 可 在 


templates/_h 





elpers.tpl 中 将 其 定义 为 子 模板 ， 然 后 通过 templates 函数 引用 。 

















这 里 mysql.fullname 是 由 release 与 chart. 二 者 名 字 拼 接 组 成 的 。 
根据 chart 的 最 佳 实践 ， 所 有 资源 的 名 称 都 应 该 保持 一 致 。 对 于 我 们 这 个 chart， 无 论 
Secret 还 是 Deployment, PersistentVolumeClaim 、Service ， 它 们 的 名 字 都 是 子 模板 
mysql.fullname 的 值 。 
(©) Chart 和 Release 是 Helm 预定 义 的 对 象 ， 每 个 对 象 都 有 自己 的 属性 ， 可 以 在 模板 中 
使 用 。 如 果 使 用 下 面 的 命令 安装 chart: 


helm install stable/mysql -n my 


e i 
e i 
e it 
e i 
e Xt 


© 这 是 
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.Chart.Name }} 的 值 为 mysql。 

.Chart.Version }} 的 值 为 0.3.0。 

.Release.Name }} 的 值 为 my。 

.Release.Service }} 始终 取 值 为 Tiller。 

template "mysql.fullname" . }} 计算 结果 为 my-mysql。 


有 指定 mysql-root-password 的 值 ， 不 过 使 用 了 if-else 的 流 控制 ， 其 逻辑 为 : 


如 


果 .Values.mysqlRootPassword 有 值 ， 就 对 其 进行 base64 编码 ,否则 随机 生成 一 个 10 位 的 字 
符 串 并 编码 。 

Values 也 是 预定 义 的 对 象 ， 代 表 的 是 values.yaml 文件 。.Values.mysqlRootPassword 则 是 
values.yaml 中 定义 的 mysqlRootPassword 参数 ， 如 图 11-28 所 示 。 





图 11-28 


因为 mysglRootPassword 被 注释 掉 了 ， 没 有 赋值 ， 所 以 逻辑 判断 会 走 else， 即 随机 生成 
密码 。 

randAlphaNum、b64enc、quote 都 是 Go 模板 语言 支持 的 函数 ， 函 数 之 间 可 以 通过 管道 | 
连接 。{{ randAlphaNum 10 | b64enc | quote }} 的 作用 是 首先 随机 产生 一 个 长 度 为 10 的 字符 
串 ， 然 后 将 其 base64 编码 ， 最 后 两 边 加 上 双 引 号 。 

templates/secrets.yaml 这 个 例子 展示 了 chart 模板 主要 的 功能 ， 我 们 最 大 的 收获 应 该 是 : 
模板 将 chart 参数 化 了 ， 通 过 values.yaml 可 以 灵活 定制 应 用 。 

无 论 多 复杂 的 应 用 , 用 户 都 可 以 用 Go 模板 语言 编写 出 chart。 无 非 是 使 用 到 更 多 的 函数 、 
对 象 和 流 控制 。 对 于 初学 者 ， 建 议 尽量 参考 官方 的 chart。 根 据 二 八 定律 ， 这 些 chart 已 经 覆 
盖 了 绝 大 部 分 情况 ， 而 且 采 用 了 最 佳 实践 。 如 何 遇 到 不 懂 的 函数 、 对 象 和 其 他 语法 ， 可 参考 官 
网 文档 https://docs.helm.sh . 


11.5.3 ”再 次 实践 MySQL chart 
学 习 了 chart 结构 和 模板 的 知识 后 , 现在 重新 实践 一 次 MySQL chart, 相信 会 有 更 多 收获 。 
1. chart 安装 前 的 准备 
作为 准备 工作 , 安装 之 前 需要 先 清楚 chart 的 使 用 方法 。 这 些 信息 通常 记录 在 values.yaml 


和 README.md 中 。 除 了 下 载 源 文件 查看 ， 执 行 helm inspect values. 可 能 是 更 方便 的 方法 ， 
如 图 11-29 所 示 。 
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ubuntuêk8s-master :~$ 

ubuntuêk8s-master:~$ helm inspect values stable/mysql 
## mysql image version 

## ref: https://hub.docker.com/r/library/mysql/tags/ 
## 

image: "mysql" 

imageTag: "5.7.14" 


## Specify password for root user 
## 
## Default: random 10 choracter string 


* mysqlRootPassword: testing 


## Create a database user 
## 

# mysqlUser: 

# mysqlPassword: 


## Allow unauthenticated access, uncomment to enable 
## 


# mysqlAllowEmptyPassword: true 





图 11-29 


输出 的 实际 上 是 values.yaml 的 内 容 。 阅读 注释 就 可 以 知道 MySQL chart. 支持 哪些 参数 ， 
安装 之 前 需要 做 哪些 准备 。 其 中 有 一 部 分 是 关于 存储 的 ， 如 图 11-30 所 示 。 


persistence: 
enobled: true 
## database data Persistent Volume Storage Class 
## If defined, storageClassName: «storageClass» 
## If set to "-", storageClassName: "", which disables dynamic provisioning 
## If undefined (the default) or set to null, no storageClassName spec is 
## set, choosing the default provisioner. (9р2 on AWS, standard оп 
## СКЕ, AWS & OpenStack) 
"n 
# storageClass: " 
: ReadWriteOnce 








图 11-30 





chart 定义 了 一 个 PersistentVolumeClaim， 申 请 8GB 的 PersistentVolume。 由 于 我 们 的 实 
验 环境 不 支持 动态 供给 ， 因 此 要 预先 创建 好 相应 的 PV， 其 配置 文件 mysql-pv.yml 的 内 容 如 
图 11-31 所 示 。 














apiVersion: v1 
kind: PersistentVolume 
metadata 
name: mysql-pv 
5рес 
accessModes 
- ReadWrite0nce 


capacity 
storage: 8Gi 
persistentVolumeReclaimPolicy: Retain 


nfs 
path: /nfsdata/mysql-pv 
server: 192.168.56.105 





图 11331 


创建 PV mysql-pv， 如 图 11-32 所 示 。 
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ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f mysql-pv.yml 
persistentvolume "mysql-pv" created 
ubuntuék8s-master:-$ 


ubuntuék8s-master:-$ kubectl get ру 

NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
mysql-pv 8Gi RWO Retain Available 

ubuntu@k8s-master:~$ 





图 11-32 
接 下 来 就 可 以 安装 chart Т. 
2. 定制 化 安装 chart 


除了 接受 values.yaml 的 默认 值 , 我 们 还 可 以 定制 化 chart, 比如 设置 mysqlRootPassword。 
Helm 有 两 种 方式 传递 配置 参数 : 


(1) 指定 自己 的 values 文件 。 通常 的 做 法 是 首先 通过 helm inspect values mysql > 
myvalues.yaml 生成 values 文件 ， 然 后 设置 mysqlRootPassword， 最 后 执行 helm install 
--values=myvalues.yaml mysql。 

(2) 通过 --set 直接 传 入 参数 值 ， 如 图 11-33 所 示 。 


ubuntuek8s-mast. 
helm install stable/mysql --set mysqlRootPasswordeabcl23 -n my 


LAST DEPLOYED: Thu Oct 19 14:24:56 2017 
NAMESPACE: default 
STATUS: DEPLOYED 


RESOURCES : 

==> v1/Service 

МАМЕ CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
my-mysql 10.104.59.139 <none> 3306/ТСР Qs 


==> vlbetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
my-mysql 1 1 1 @ 95 


v1/Secret 
NAME TYPE DATA AGE 
my-mysql Opaque 2 ðs 


==> v1/PersistentVolumeCloim 
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
my-mysql Pending 05 





图 11-33 


mysqlRootPassword 设置 为 abc123。 另外 , -n 设置 release 为 my， 各 类 资源 的 名 称 即 为 
my-mysql。 
通过 helm list 和 helm status. 可 以 查看 chart 的 最 新 状态 ， 如 图 11-34 所 示 。 
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ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm list 

NAME REVISION UPDATED STATUS CHART МАМЕЅРАС 
пу 1 Thu Oct 19 14:24:56 2017 DEPLOYED mysql-0.3.0 default 
ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ helm status my 

LAST DEPLOYED: Thu Oct 19 14:24:56 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 
==> v1/Secret 
NAME TYPE DATA AGE 


my-mysql Opaque 2 8m 


istentVolumeClaim 
VOLUME САРАСТТҮ ACCESSMODES STORAGECLASS AGE 
mysql-pv 8Gi RWO 8n 


==> vi/Service 
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
my-mysql 10.104.59.139 <none> 3306/TCP 8m 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE 
my-mysql 1 1 1 





11-34 


PVC 已 经 Bound，Deployment 也 变 为 AVAILABLE。 


11.5.4 “升级 和 回 滚 release 


release 发 布 后 可 以 执行 helm upgrade 对 其 进行 升级 ， 通 过 --values 或 --set 应 用 新 的 配 
置 。 比 如 将 当前 的 MySQL 版 本 升级 到 5.7.15, WE 11-35 所 示 。 


ubuntu@k8s-master :~$ 

ubuntuék8s-master:-$ helm upgrade --set ітадеТад=5.7.15 my stable/mysq 
Release "my" has been upgraded. Happy Helming! 

LAST DEPLOYED: Thu 0ct 19 14:37:46 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES : 

v1/Secret 
NAME ТҮРЕ DATA АСЕ 
my-mysql Opaque 2 12m 


==> vi/PersistentVolumeClaim 
NAME STATUS VOLUME CAPACITY ACCESSMODES ЅТОКАСЕСІА55 AGE 
my-mysql Bound mysql-pv 861 RWO 12т 


==> v1/Service 
МАМЕ CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
my-mysql 10.104.59.139 <none> 3306/TCP 12m 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE АСЕ 
my-mysql 1 1 2l 0 12т 





图 11-35 


等 待 一 些 时 间 ， 升 级 成 功 ， 如 图 11-36 所 示 。 


118 


ubuntuék8s-master:-$ kubectl get deployment my-mysql -o wide 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) 
1 


my-mysql 1 1 1 
ubuntuék8s-master:-$ 


Sm my-mysql 





# 11-36 


helm history 可 以 查看 release 所 有 的 版 本 。 通过 helm rollback 可 以 


图 11-37 所 示 。 


ubuntu@k8s-master:~$ helm history my 

REVISION UPDATED STATUS 

1 Thu Oct 19 11:18:55 2017 SUPERSEDED 
2 Thu Oct 19 11:20:01 2017 DEPLOYED 
ubuntuék8s-master:--$ 

ubuntuék8s-master:-$ helm rollback my 1 

Rollback was a success! Happy Helming! 
ubuntuék8s-master:-$ 


图 11-37 
回 滚 成 功 ，MySQL 恢复 到 5.7.14, ng 11-38 所 示 。 





ubuntuék8s-master:-$ helm history my 
REVISION UPDATED STATUS CHART 
Thu 0ct 19 11 5 2017 SUPERSEDED 
Thu 0ct 19 11 1 2017 SUPERSEDED 
Thu 0ct 19 11:27:01 2017 DEPLOYED 
uvbuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get deployment my-mysql -о wide 





E 











滚 到 任何 版 本 ， 如 


CHART DESCRIPT. 
mysql-0.3.0 Install 
mysql-0.3.0 Upgrade 





DESCRIPTION 
Install complete 


Upgrade complete 
Rollback to 1 


НАМЕ DESIRED CURRENT  UP-TO-DATE AVAILABLE AGE CONTAINERCS) 
my-mysql 1 1 1 1 8т my-mysql 


ubuntuek8s-master: 


图 11-38 


11.5.55 “开发 自己 的 chart 


Kubernetes 给 我 们 提供 了 大 量 官方 chart， 不 过 要 部 署 微服 务 应 用 ， 还 是 需 








chart， 下 面 就 来 实践 这 个 3 
1. 创建 chart 


: 题 。 








要 开发 自己 的 





执行 helm create mychart 命令 ， 创 建 chart mychart， 如 图 11-39 所 示 。 


ubuntuek8s-master:-$ 
ubuntuék8s-master:-$ helm create mychart 
Creating mychart 
ubuntuek8s-maste: 
ubuntuék8s-master:-$ tree mychart 
mychart 
| 一 charts 
I— Chart.yaml 
| 一 templates 

I— deployment .yaml 

I— .helpers.tpl 


I 

I 

1 К— ingress.yaml 
1 | 一 NOTES .txt 

| ї1— service.yanl 
L— values.yaml 


2 directories, 7 files 
ubuntuek8s-master:-$ 


图 11-39 
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Helm 会 帮 我 们 创建 目录 mychart, 并 生成 各 类 chart 文件 。 这 样 我 们 就 可 以 在 此 基础 上 
发 自己 的 chart 了 。 
新 建 的 chart 默认 包含 一 个 nginx 应 用 示例 ，values.yaml 内 容 如 图 11-40 所 示 。 

















a ar 1riable 
replicaCount 1 
image: 

repository: nginx 

tag: stable 

pullPolicy: IfNotPresent 
Service: 


name: nginx 

type: CLusterIP 

externalPort: 80 

internalPort: 80 
ingress: 


hosts: 
- chart-example.local 





图 11-40 

开发 时 建议 大 家 参考 官方 chart. 中 的 模板 values.yaml、Chart.yaml， 里 面包 含 了 大 量 最 佳 
实践 和 最 常用 的 函数 、 流 控制 ， 这 里 就 不 一 一 展开 了 。 

2. 调试 chart 

只 要 是 程序 就 会 有 bug, chart 也 不 例外 。Helm 提供 了 debug 的 工具 : helm lint 和 helm 
install --dry-run --debug。 

helm lint 会 检测 chart 的 语法 ， 报 告 错误 以 及 给 出 建议 。 

比如 我 们 故意 在 values.yaml 的 第 8 行 漏 掉 了 行 尾 的 那个 冒号 ， 如 图 11-41 所 示 。 





replicaCount: 1 
image: 

repository: nginx 
t stable 


3 [ pullPolicy IfNotPresent 


9 service: 
пате: nginx 
type: ClusterIP 
externalPort: 8@ 
internalPort: 8@ 


图 1141 


helm lint mychart 会 指出 这 个 语法 错误 ， 如 图 11-42 所 示 。 
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ubuntuék8s-master:-$ 
ubuntuék8s-master:-$ helm lint mychart 
==> Linting mychart 
[INFO] Chart.yaml: icon is recommended 


[ERROR] values.yaml: unable to parse YAML 

error converting YAML to JSON: yaml: line 8: could not find expected ':" 
Error: 1 chart(s) linted, 1 chart(s) failed 
ubuntuek8s-master:-$ 





图 11-42 


mychart 目录 被 作为 参数 传递 给 helm lint。 错 误 修复 后 则 能 通过 检测 ， 如 图 11-43 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-maste, helm lint mychart 
Linting mychart 

[INFO] Chart.yaml: icon is recommended 


1 chart(s) linted, no failures 
ubuntuek8s-master:-$ 





图 1143 
每 个 模板 生成 的 YAML 内 容 , 如 





helm install --dry-run --debug 会 模拟 安装 chart, 并 输 
图 11-44、 图 11-45 所 示 。 


ubuntuek8s-master:-$ 
ubuntuek8s-master:-$ helm install --dry-run mychart --debug 
[debug] Created tunnel using local port: '46295' 


[debug] SERVER: "localhost:46295" 
[debug] Original chart version: "" 
[debug] CHART PATH: /home/ubuntu/mychart 


NAME:  solitary-kudu 

REVISION: 1 

RELEASED: Fri Oct 20 09:59:51 2017 
CHART: mychart-0.1.0 

USER-SUPPLIED VALUES: 

і 


COMPUTED VALUES: 
image: 
pullPolicy: IfNotPresent 
repositor nginx 
tag: stable 
ingress: 
annotations: null 
enabled: false 
hosts: 
- chart-example.local 
tls: null 
replicaCount: 1 
resources: {} 
service: 
externalPort: 80 
internalPort: 80 
name: nginx 
type: ClusterIP 


HOOKS : 
MANIFEST: 





图 11-444 
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* Source: mychart/templates/service.yaml 
apiVersion: vi 
kind: Service 
metadata: 
name: solitary-kudu-mychart 
labels: 
app: mychart 
chart: mychart-0.1.0 
release: solitary-kudu 
heritage: Tiller 
spec: 
type: ClusterIP 
ports: 
- port: 80 
targetPort: 80 
protocol: TCP 
name: nginx 
selector: 
app: тусһаг+ 
release: solitary-kudu 
# Source: mychart/templates/deployment.yoml 
apiVersion: extensions/vlbetal 
kind: Deployment 
metadata: 
name: solitary-kudu-mychart 
labels: 


арр: тусһаг+ 

chart: mychart-0.1.0 
release: solitary-kudu 
heritage: Tiller 


spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: mychart 
release: solitary-ku 
spec: 
containers: 
- name: mychart 
image: "nginx:stable" 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort: 80 
livenessProbe: 
httpGet: 
path: / 
port: 80 
readinessProbe: 
httpGet: 
path: / 
port: 80 
resources: 





图 11-45 
我 们 可 以 检测 这 些 输出 ， 判 断 是 否 与 预期 相符 。 
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同样 ，mychart 目录 作为 参数 传递 给 helm install --dry-run --debug。 


3. 安装 chart 


可 以 


当 我 们 准备 就 绪 ， 就 可 以 安装 chart f. Helm 支持 四 种 安装 方法 : 


(1) 安装 仓库 中 的 chart， 例 如 helm install stable/nginx 。 

(2) 通过 tar 包 安 装 ， 例 如 helm install .nginx-1.2.3.tgz。 

(3) 通过 chart 本 地 目录 安装 ， 例 如 helm install /пріпх 

(4) 通过 URL 安装 ， 例 如 helm install https://example.com/charts/nginx-1.2.3.tgz o 


有 我 们 使 用 本 地 目录 安装 ， 如 图 11-46 所 示 。 








这 是 


ubuntu@k8s-master:~$ 


ubuntu@k8s-maste helm install mychart 


opinionated-nightingale 


LAST DEPLOYED: Fri Oct 20 10:14:06 2017 


NAMESPACE: default 
STATUS: DEPLOYED 


RESOURCES: 

==> v1/Service 
NAME CLUSTER-IP 
opinionated-nightingale-mychart 10.100.28.221 


==> vl1betal/Deployment 


NAME DESIRED CURRENT UP-TO-DATE 


opinionated-nightingale-mychart 1 


NOTES: 


1. Get the application URL by running these commands 
export POD NAME-$(kubectl get pods --namespace default - 
echo "Visit http://127.0.0.1:8080 to use your application" 


1 


kubectl port-forward $POD NAME 8080:80 


ubuntuéek8s-master :~$ 


当 chart 部 署 到 Kubernetes 集群 后 ， 便 可 以 对 其 进行 更 为 全 面 的 测试 了 。 


4. 将 chart 添加 到 仓库 
chart 通过 测试 后 可 以 添加 到 仓库 中 ， 














:~# 
:~# mkdir /var/www 
E 


:~# docker run -d -p 8080:80 -v /var/www/:/usr/local/apache2/htdocs/ httpd 
f3d5f0779a04a3074bd332764263e0283d8548e8f9b2b96dc744e098b45ce075 
rootek8s-node1 :~# 








图 1146 


EXTERNAL-IP PORT(S) AGE 


AVAILABLE AGE 


"арр=тусһаг+ ,release=opi 


团队 其 他 成 员 就 能 够 使 用 了 。 任何 HTTP Server 都 





HIE chart 仓库 。 下 面 演示 在 k8s-nodel 192.168.56.106 上 搭建 仓库 。 
(1) 在 k8s-nodel 上 启动 一 个 httpd 容器 ， 如 图 11-47 所 示 。 


图 11-47 
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(2) 通过 helm package 将 mychart 打包 ， 如 图 11-48 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm package mychart 


Successfully packaged chart and saved it to: /home/ubuntu/mychart-0.1.0.tgz 
ubuntuek8s-master:-$ 





图 11-48 


(3) 执行 helm repo index 生成 仓库 的 index 文件 ， 如 图 11-49 所 示 。 
:-$ 


mkdir myrepo 
mv mychart-0.1.0.tgz myrepo/ 
=$ helm repo index myrepo/ --url http://192.168.56.106:8080/charts 
ubuntuék8s-master:-$ ls myrepo/ 
index.yaml  mychart-0.1.0.tgz 
ubuntuek8s-master:-$ 





K 11-49 


Helm 会 扫描 myrepo 目录 中 的 所 有 tgz 包 并 生成 index yaml. --url 指定 的 是 新 仓库 的 
访问 路 径 。 新 生成 的 index.yaml 记录 了 当前 仓库 中 所 有 chart 的 信息 ， 如 图 11-50 所 示 。 


apiVersion: vl 
entries: 
mychart: 
- apiVersion: v1 
created: 2017-10-21T16:39:39.184818935408:00 
description: A Helm chart for Kubernetes 
digest: ae8d71380024432014dc8638ec37202823e9207445caf08a2660d154b26e936ea 
name: mychart 
urls: 
- http://192.168.56.106:8080/charts/mychart-0.1.0.tgz 
version: 0.1.0 
generated: 2017-10-21716:39:39.184265707+08:00 





图 11-50 


当前 只 有 mychart 这 一 个 chart, 
(4) 将 mychart-0.1.0.tgz 和 index.yaml 上 传 到 k8s-nodel 的 /var/www/charts 目录 ， 如 
图 11-51 所 示 。 


rootek8s-node1:-£ 
rooték8s-nodel:-£ ls /var/www/charts/ 


index.yaml  mychart-0.1.0.tgz 
root@k8s-nodel:~# 





图 11-51 


(5) 通过 helm repo add 将 新 仓库 添加 到 Helm， 如 图 11-52 所 示 。 
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ubuntuek8s-master:~4 

ubuntuék8s-master:-$ helm repo add newrepo http://192.168.56.106:8080/charts| 
"newrepo" has been added to your repositories 

ubuntuek8s-master :~$ 

ubuntuék8s-master:-$ helm repo list 


NAME URL 
stable https://kubernetes-charts.storage.googleapis.com 
local ht 


newrepo http://192.168.56.106:8080/charts 





图 11-52 


仓库 命名 为 newrepo，Helm 会 从 仓库 下 载 index.yaml。 
(6) 现在 已 经 可 以 repo search 到 mychart 了 ， 如 图 11-53 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm search mychart 

NAME VERSION DESCRIPTION 

local/mychart 0.1.0 А Helm chart for Kubernetes 
newrepo/mychart 0.1.0 A Helm chart for Kubernetes 
ubuntuek8s-master:-$ 





图 11-53 


除了 newrepo/mychart, 这 里 还 有 一 个 local/mychart。 这 是 因为 在 执行 第 2 步 打 包 操 作 的 
同时 ，mychart 也 被 同步 到 了 local 的 仓库 。 


:~$ helm install newrepo/mychart 
guilded-jellyfish 
LAST DEPLOYED: Sat Oct 21 16:49:31 2017 
NAMESPACE: default 
STATUS: DEPLOYED 


RESOURCES : 

==> v1/Service 

NAME CLUSTER-IP EXTERNAL-IP  PORTCS) АСЕ 
guilded-jellyfish-mychart 10.109.0.87 <none> 80/TCP А 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
guilded-jellyfish-mychort 1 16 1 0 0s 


NOTES : 

1. Get the арр11са+1оп URL by running these commands : 
export POD NAME-$(kubectl get pods --namespace default -l "app=mychort,r. 
echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD NAME 8080:80 





图 11-54 


(8) 若 以 后 仓库 添加 了 新 的 chart， 则 需要 用 helm repo update 更 新 本 地 的 index, "nf 
11-55 所 示 。 
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ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ helm repo update 

Hang tight while we grab the latest from your chart repositories... 
...Skip local chart repository 


...Successfully got an update from the "newrepo" chart repository 
...Successfully got an update from the "stable" chart repository 
Update Complete. $ Happy Helming! $ 

ubuntuék8s-master: ~$ 





图 11-55 





这 个 操作 相当 于 Ubutun 的 apt-get update. 





小 结 


本 章 我 们 学 习 了 Kubernetes 包 管 理 器 Helm. 

Helm 让 我 们 能 够 像 apt 管理 deb 包 那 样 安装 、 部 署 、 升 级 和 删除 容器 化 应 用 。 

Helm 由 客户 端 和 Tiller 服务 器 组 成 。 客 户 端 负责 管理 chart， 服 务 器 负责 管理 release. 
chart 是 Helm 的 应 用 打包 格式 ， 它 由 一 组 文件 和 目录 构成 。 其 中 最 重要 的 是 模板 ， 模 板 





























中 定义 了 Kubernetes 各 类 资源 的 配置 信息 ，Helm 在 部 署 时 通过 values.yaml 实例 化 模板 。 





Helm 允许 用 户 开发 自己 的 chart， 并 为 用 户 提供 了 调试 工具 。 用 户 可 以 搭建 自己 的 chart 


仓库 ， 在 团队 中 共享 chart。 
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Helm 帮助 用 户 在 Kubernetes 上 高 效 地 运行 和 管理 微服 务 架构 应 用 ，Helm 非常 重要 。 





本 章 我 们 讨论 Kubernetes 网 络 这 个 重要 主题 。 

Kubernetes 作为 编排 引擎 管理 着 分 布 在 不 同 节点 上 的 容器 和 Pod。Pod、Service、 外 部 组 
件 之 间 需 要 一 种 可 靠 的 方式 找到 彼此 并 进行 通信 ，Kubernetes 网 络 则 负责 提供 这 个 保障 。 本 
章 包括 如 下 内 容 : 


(1) Kubernetes 网 络 模型 。 
(2) 各 种 网 络 方案 。 
(3) Network Policy。 


1 2.1 Kubernetes 网 络 模型 


Kubernetes 采用 的 是 基于 扁平 地 址 空间 的 网 络 模型 ， 集 群 中 的 每 个 Pod 都 有 自己 的 IP 
地 址 ，Pod 之 间 不 需要 配置 NAT 就 能 直接 通信 。 另 外 ， 同 一 个 Pod 中 的 容器 共享 Pod 的 
IP， 能 够 通过 localhost 通信 。 

这 种 网 络 模型 对 应 用 开发 者 和 管理 员 相当 友好 ， 应 用 可 以 非常 方便 地 从 传统 网 络 迁移 到 
Kubernetes。 每 个 Pod 可 被 看 作 是 一 个 个 独立 的 系统 ， 而 Pod 中 的 容器 则 可 被 看 作 同 一 系统 
中 的 不 同 进程 。 

下 面 讨论 在 这 个 网 络 模型 下 集群 中 的 各 种 实体 如 何 通 信 。 知 识 点 前 面 都 已 经 涉及 , 这 里 可 
当 作 复 习 和 总 结 。 

1. Pod 内 容器 之 间 的 通信 

当 Pod 被 调度 到 某 个 节点 ，Pod 中 的 所 有 容器 都 在 这 个 节点 上 运行 ， 这 些 容器 共享 相同 
的 本 地 文件 系统 、IPC 和 网 络 命名 空间 。 

不 同 Pod 之 间 不 存在 端口 冲突 的 问题 ， 因 为 每 个 Pod 都 有 自己 的 IP 地 址 。 当 某 个 容 
器 使 用 localhost 时 ， 意 味 着 使 用 的 是 容器 所 属 Pod 的 地 址 空间 。 

比如 Pod А 有 两 个 容器 container-Al 和 container-A2, container-Al 在 端口 1234 上 监 
听 ， 当 container-A2 连接 到 localhost:1234 时 ， 实 际 上 就 是 在 访问 container-A1。 这 不 会 与 同 
一 个 节点 上 的 Pod В 冲突 ， 即 使 Pod B 中 的 容器 container-B1 也 在 监听 1234 端口 。 





2. Pod 之 间 的 通信 
Pod 的 IP 是 集群 可 见 的 ， 即 集群 中 的 任何 其 他 Pod 和 节点 都 可 以 通过 IP 直接 与 Pod 
通信 ， 这 种 通信 不 需要 借助 任何 网 络 地 址 转换 、 隧 道 或 代理 技术 。Pod 内 部 和 外 部 使 用 的 是 
同一 个 IP， 这 也 意味 着 标准 的 命名 服务 和 发 现 机 制 ， 比 如 DNS 可 以 直接 使 用 。 
3. Pod 与 Service 的 通信 


Pod 间 可 以 直接 通过 IP 地 址 通信 ， 但 前 提 是 Pod 知道 对 方 的 IP。 在 Kubernetes 集群 中 ， 
Pod 可 能 会 频繁 地 销毁 和 创建 ,也 就 是 说 Pod 的 IP 不 是 固定 的 。 为 了 解决 这 个 问题 , Service 提 
供 了 访问 Pod 的 抽象 层 。 无 论 后 端的 Pod 如 何 变化 ，Service 都 作为 稳定 的 前 端 对 外 提供 服 
务 。 同 时 ，Service 还 提供 了 高 可 用 和 负载 均衡 功能 ，Service 负责 将 请 求 转发 给 正确 的 Pod. 

4. 外 部 访问 

无 论 是 Pod 的 IP 还 是 Service 的 Cluster IP， 它 们 只 能 在 Kubernetes 集群 中 可 见 ， 对 集群 
之 外 的 世界 ， 这 些 IP 都 是 私有 的 。 

Kubernetes 提供 了 两 种 方式 让 外 界 能 够 与 Pod 通信 : 

€ NodePort。Service 通过 Cluster 节点 的 静态 端口 对 外 提供 服务 。 外 部 可 以 通过 

<NodeIP>:<NodePort> 访问 Service, 
@ LoadBalancer。Service 利用 cloud provider 提供 的 load balancer 对 外 提供 服务 ， 


cloud provider 负责 将 load balancer 的 流量 导向 Service。 目 前 支持 的 cloud provider 
有 GCP、AWS、Azur 等 。 












































各 种 网 络 方案 


网 络 模型 有 了 ， 如 何 实现 呢 ? 

为 了 保证 网 络 方案 的 标准 化 、 扩 展 性 和 灵活 性 ，Kubernetes 采用 了 Container Networking 
Interface CCND 规范 。 

CNI 是 由 CoreOS 提出 的 容器 网 络 规范 ， 使 用 了 插件 (Plugin) 模型 创建 容器 的 网 络 栈 ， 
如 图 12-1 所 示 。 
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Container Network Interface (CNI) Drivers 


Container 
Runtime 


Container Network Interface (CNI) 


Loopback Bridge PTP MACvlan IPvlan 3rd-Party 
Plugin Plugin Plugin Plugin Plugin Plugin 


图 12-1 


СМІ 的 优点 是 支持 多 种 容器 runtime， 不 仅仅 是 Dockers СМІ 的 插件 模型 支持 不 同 组 织 
和 公司 开发 的 第 三 方 插件 ， 这 对 运 维 人 员 来 说 很 有 吸引 力 ， 可 以 灵活 选择 适合 的 网 络 方案 。 

目前 已 有 多 种 支持 Kubernetes 的 网 络 方案 , 比如 Flannel, Calico, Canal. Weave Net 等 。 
因为 它们 都 实现 了 СМІ 规范 ， 用 户 无 论 选择 哪 种 方案 ,得 到 的 网 络 模 型 都 一 样 ， 即 每 个 Pod 
都 有 独立 的 IP, 可 以 直接 通信 。 区别 在 于 不 同方 案 的 底层 实现 不 同 , 有 的 采用 基于 VxLAN 的 
Overlay 实现 ， 有 的 则 是 Underlay， 性 能 上 有 区 别 。 再 有 就 是 是 否 支持 Network Policy. 


1 2 .З Network Policy 


Network Policy 是 Kubernetes 的 一 种 资源 。Network Policy 通过 Label 选择 Pod， 并 指 
定 其 他 Pod 或 外 界 如 何 与 这 些 Pod 通信 。 

默认 情况 下 ， 所 有 Pod 是 非 隔 离 的 ， 即 任何 来 源 的 网 络 流量 都 能 够 访问 Pod， 没 有 任何 
限制 。 当 为 Pod 定义 了 Network Policy 时 ， 只 有 Policy 允许 的 流量 才能 访问 Pod. 

不 过 , 不 是 所 有 的 Kubernetes 网 络 方案 都 支持 Network Policy。 比 如 Flannel 就 不 支持 ， 
Calico 是 支持 的 。 我 们 接 下 来 将 用 Canal 来 演示 Network Policy。Canal 这 个 开源 项 目 很 有 
意思 ， 它 用 Flanel 实现 Kubernetes 集群 网 络 ， 同 时 又 用 Calico 实现 Network Policy. 





12.3.1 部 署 Canal 


部 署 Canal 与 部 署 其 他 Kubernetes 网 络 方案 非常 类 似 ， 都 是 在 执行 了 kubeadm init 初 
始 化 Kubernetes 集群 之 后 通过 kubectlapply 安装 相应 的 网 络 方案 。 也 就 是 说 , 没有 太 好 的 办 
法 直接 切换 使 用 不 同 的 网 络 方案 ， 基 本 上 只 能 重新 创建 集群 。 

要 销毁 当前 集群 ,最 简单 的 方法 是 在 每 个 节点 上 执行 kubeadm reset, 然后 就 可 以 按照 3.3.1 
小 节 “ 初 始 化 Master” 中 的 方法 初始 化 集群 了 。 


kubeadm init --apiserver-advertise-address 192.168.56.105 
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--pod-network-cidr-10.244.0.0/16 


然后 按照 文档 https;//kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ 安装 
Canal。 文 档 列 出 了 各 种 网 络 方案 的 安装 方法 ， 如 图 12-2 所 示 。 





Choose опе... Calico Flannel Kube-router Romana Weave Net 


The official Canal set-up guide is here. 


Note: 


* For Canal to work correctly, --pod-network-cidr-18.244.8.0/16 has to be passed to kubeadm init 


* Canal works on amd64 only. 


kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1. 
kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master /k8s-install/1. 








图 12-2 
执行 如 下 命令 部 署 Canal: 


kubectl apply -f 
https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.7/r 
bac.yaml 

kubectl apply -f 
https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.7/c 
anal.yaml 


部 署 成 功 后 ， 可 以 查看 到 Canal 相关 组 件 ， 如 图 12-3 所 示 。 


ubuntu@k8s-master:~$ 

ubuntuek8s-maste kubectl get --namespace-kube-system daemonset canal 

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE 
canal x ЕЈ 3 3 zi «none» 54 
ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ kubectl get --namespace-kube-system pod -o widelgrep canal 

canal-fkrl& 3⁄3 Running 0 5d 192.168.56.107 k8s-node2 
сапа1-рауа2 3⁄3 Running Q 5а 192.168.56.105  k8s-maste 
canal-wtlhk 3⁄3 Running 0 5d 192.168.56.106 k8s-node1 
ubuntuék8s-master:-$ 





图 12-3 





Canal 作为 DaemonSet 部 署 到 每 个 节点 ， 属 于 kube-system 这 个 namespace. 


12.3.2 ”实践 Network Policy 


为 了 演示 Network Policy, 我 们 先 部 署 一 个 httpd 应 用 , 其 配置 文件 httpd.yaml 如 图 12-4 
所 示 。 
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apiVersion: apps/vibetal 
kind: DepLoyment 
metadata: 
name: httpd 
spec: 
replicas 
template: 
metadata 
labels 
run: httpd 
spec 
contoiners 
name: httpd 
image: httpd:latest 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort 


apiVersion: vl 
kind: Service 
metadata 
name: httpd-svc 
spec: 
type: NodePort 
selector: 
run: httpd 
ports: 
protocol: TCP 
nodePort 
port 
targetPort: 





图 12-4 


httpd 有 三 个 副本 ， 通 过 NodePort 类 型 的 Service 对 外 提供 服务 。 部 署 应 用 ， 如 图 12-5 
所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 

deployment "httpd" created 

service "httpd-svc" created 

ubuntuek8s-master: ~$ 

ubuntuék8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE NODE 
httpd-b5c6f48-gs7p2 3⁄4 Running 0 5 mis k8s-node1 


httpd-b5c6f48-p86tv 1/1 Running 0 ë xd k8s-node1 
httpd-b5c6f48-qxzxg 1/1 Running 0 。 „2. k8s-node2 
ubuntuek8s-master: ~$ 

ubuntuék8s-master:-$ kubectl get service httpd-svc 

NAME ТҮРЕ CLUSTER-IP EXTERNAL-IP РОВТ(5) 

httpd-svc NodePort 10.104.77.239 <none> 8080:30000/TCP 2m 
ubuntu@k8s-master:~$ 





图 12-5 
当前 没有 定义 任何 Network Policy， 验 证 应 用 可 以 被 访问 ， 如 图 12-6 所 示 。 
(1) 启动 一 个 busybox Pod， 既 可 以 访问 Service， 也 可 以 Ping 到 副本 Pod. 
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ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter 


100% 


/ # ping 10.244.1.7 

PING 10.244.1.7 (10.2 
64 bytes from 10.244. 
64 bytes from 10.244. 
64 bytes from 10.244. 





CD 定义 将 此 Network Policy 中 的 访问 规则 应 用 了 


/ # wget httpd-svc:8080 
Connecting to httpd-svc:8080 (10.104.77.239:8080) 


ЕЕЕ ЕЕЕ КЕКЕК ЖЕЕ 


4.1.7): 56 data bytes 


nte 
z 
ГАЗ 





(2) 集群 节点 既 可 以 访问 Service， 也 可 以 Ping 到 副本 Роа, WK 12-7 所 示 。 


root@k8s-node2:~# 
root@k8s-node2:~# curl 10.104.77.239:8080 
<html><body><h1>It works!«/h1»«/body»«/html» 
root@k8s-node2:~# 
root@k8s-node2:~# ping -c 3 10.244.1.7 
PING 190.244.1.7 (10.244.1.7) 56(84) bytes of data. 
64 bytes from 10.244.1. 
4 bytes from 10.244.1. 
64 bytes from 10.244.1. icmp.seq-3 ttl-63 time-0.495 ms 





图 12-7 


(3) 集群 外 〈192.168.56.1) 可 以 访问 Service, WE 12-8 所 示 。 


~ curl 192.168.56.106:30000 
«html»«body»«hi»It works!«/h1»«/body»«/html» 





图 12-8 


现在 创建 Network Policy, ШШ 12-9 所 示 。 


kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata 
name: access-httpd 
spec 
podSelector 
matchLabels 
run: httpd 
ingress 
from 
- podSelector 
matchLabels 
access 


ports 
- protocol: TCP 
port 


图 12-9 





F label 为 run: httpd 的 Pod, HJ 


httpd 








应 用 的 三 个 副本 Pod. 
@ ingress 中 定义 只 有 label 为 access: "true" 的 Pod 才能 访问 应 用 。 
@) 只 能 访问 80 端口 。 
通过 kubectl apply 创建 Network Policy， 如 图 12-10 所 示 。 








ubuntuék8s-master:-$ 

ubuntuék8s-master:-$ kubectl apply -f policy.yaml 
networkpolicy "access-httpd" created 
ubuntuek8s-master: -$ 


ubuntuék8s-master:-$ kubectl get networkpolicy 
NAME POD-SELECTOR AGE 
access-httpd ru ttpd 32s 
ubuntu@k8s-master:~$ 





图 12-10 
验证 Network Policy 的 有 效 性 : 
(1) busybox Pod 已 经 不 能 访问 Service， 如 图 12-11 所 示 。 


ubuntuék8s-master :~$ 

ubuntuék8s-master:-$ kubectl run busybox --rm -ti --image-busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

Z e 

/ # wget httpd-svc:8080 --timeout-5 

Connecting to httpd-svc:8080 (10.104.77.239:8080) 

wget: download timed out 

/ # 





图 12-11 


如 果 Pod 添加 了 label access: "true" 就 能 访问 到 应 用 , 但 Ping 已 经 被 禁止 ， 如 图 12-12 
所 示 。 


$ kubectl run busybox --rm -t image-busybox /bin/sh 
If you don't see a command prompt, try pressing 
/ 
/ # wget httpd-svc:8080 
Connecting to httpd-svc:8080 (10.104.77.239:8080) 
index.html 100% | | 45 0:00:04 
АЕ 
/ # ping -c 3 10.244.1.7 
PING 10.244.1.7 (10.244.1.7): 56 dota bytes 


--- 10.244.1.7 ping statistics --- 
3 packets transmitted, 0 packets received, 100% packet loss 
/ # 





图 12-12 





(2) 集群 节点 已 经 不 能 访问 Service, t& Ping 不 到 副本 Pod, ШЖ 12-13 所 示 。 
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root@k8s-node2:~# curl 10.104.77.239:8080 --connect-timeout 5 
curl: (28) Connection timed out after 5001 milliseconds 
Irootek8s -node2 : i 

root@k8s-node2:~# ping -c 3 190.244.1.7 


PING 10.244.1.7 (190.244.1.7) 56(84) bytes of data. 


--- 10.244.1.7 ping statistics --- 
3 packets transmitted, 0 received, 100X packet loss, time 1999ms 





图 12-13 


(3) 集群 外 (192.168.56.1) 已 经 不 能 访问 Service, Ш 12-14 所 示 。 


+ ~ 
3 ~ curl 192.168.56.106:30000 --connect-timeout 5 
curl: (28) Connection timed out after 5003 milliseconds 
265 





E 12-14 


如 果 希 望 让 集群 节点 和 集群 外 (192.168.56.1) 也 能 够 访问 到 应 用 , 可 以 对 Network Policy 
做 如 图 12-15 所 示 的 修改 。 


kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata 
name: access-httpd 
spec 
podSelector: 
matchLabels : 
run: httpd 
ingress: 
- from: 
- podSelector: 
matchLabels: 
access: 


- protocol: TCP 
port: 





图 12-15 


应 用 新 的 Network Policy， 如 图 12-16 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f policy.yaml 


networkpolicy "access-httpd" configured 
ubuntuék8s-master:-$ 





图 12-16 


群 节点 和 集群 外 〈192.168.56.1) 已 经 能 够 访问 了 ， 如 图 12-17. K 12-18 所 示 。 


iud 


ME, 8 
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root@k8s-node2:~# 
root@k8s-node2:~# curl 10.104.77.239:8080 


<html><body><h1>It works!«/h1»«/body»«/html» 
root@k8s-node2:~# 





图 12-17 


ә ~ 
> ~ curl 192.168.56.106:30000 


<html><body><h1>It works!«/h1»«/body»«/html» 
ә ~ 





图 12-18 


除了 通过 ingress 限制 进入 的 流量 ， 也 可 以 用 egress 限制 外 出 的 流量 。 大 家 可 以 参考 官 
网 相关 文档 和 示例 ， 这 里 就 不 资 述 了 。 


C.C 小 结 
Kubernetes 采用 的 是 扁平 化 的 网 络 模型 ， 每 个 Pod 都 有 自己 的 IP， 并 且 可 以 直接 通信 。 


CNI 规范 使 得 Kubernetes 可 以 灵活 选择 多 种 Plugin 实现 集群 网 络 。 
Network Policy 赋予 了 Kubernetes 强大 的 网 络 访问 控制 机 制 。 
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第 13 = 
Kubernetes Dashboard 


前 面 章 节 Kubernetes 所 有 的 操作 我 们 都 是 通过 命令 行 工 具 kubectl 完成 的 。 为 了 提供 更 
丰富 的 用 户 体验 ，Kubernetes 还 开发 了 一 个 基于 Web 的 Dashboard, 用 户 可 以 用 Kubernetes 
Dashboard 部 署 容器 化 的 应 用 、 监 控 应 用 的 状态 、 执 行 故 障 排查 任务 以 及 管理 Kubernetes 的 
各 种 资源 。 

在 Kubernetes Dashboard 中 可 以 查看 集群 中 应 用 的 运行 状态 ， 也 能 够 创建 和 修改 各 种 
Kubernetes 资源 ， 比 如 Deployment, Job. DaemonSet 等 。 用 户 可 以 Scale Бр 
Deployment、 执 行 Rolling Update、 重 启 某 个 Pod 或 者 通过 向 导 部 署 新 的 应 用 。Dashboard fi 
显示 集群 中 各 种 资源 的 状态 以 及 日 志 信息 

可 以 说 ，Kubernetes Dashboard 提供 了 kubectl 的 绝 大 部 分 功能 ， 大 家 可 以 根据 情况 进行 











安装 


Kubernetes 默认 没有 部 署 Dashboard， 可 通过 如 下 命令 安装 : 


kubectl create -f 
https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recom 
mended/kubernetes-dashboard.yaml 


Dashboard 会 在 kube-system namespace 中 创建 自己 的 Deployment 和 Service, 如 图 13-1 
所 示 。 


ubuntu@k8s-master:~$ kubectl --namespace=kube-system get deployment kubernetes-dashboard 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-dashboard 1 A 1 + 17h 

ubuntuék8s master :~$ 


ubuntuék8s-master:-$ kubectl --namespace-kube-system get service kubernetes-dashboard 
NAME ТҮРЕ CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
kubernetes-dashboard ^ ClusterIP 10.110.199.111 <none> 443/TCP 17h 





图 13-1 














因为 Service 是 ClusterIP 类 型 ,为 了 方便 使 用 ,我 们 可 通过 kubectl --namespace=kube-system 
edit service kubernetes-dashboard 修改 成 NodePort 类 型 ， 如 图 13-2 所 示 。 











spec 
clusterIP: 10.110.199.111 
ports 
port 
protocol: TCP 
targetPort: 


selector 
k8s-app: kubernetes-dashboard 
sessionAffinity: None 
status: 
loadBalancer: 





图 13-2 
保存 修改 ， 此 时 已 经 为 Service 分 配 了 端口 31614， 如 图 13-3 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl --namespace-kube-system get service kubernetes-dash| 


МАМЕ ТҮРЕ CLUSTER-IP EXTERNAL-IP РОКТСЅ 


kubernetes-dashboard ^ NodePort — 10.110.199.111 <none> 443:31614/TCP 
ubuntuek8s-master : -$ 





13-3 


通过 浏览 器 访问 Dashboard https://192.168.56.105:31614/， 登 录 界 面 如 图 13-4 所 示 。 


Kubernetes Dashboard 


Authentication method: 
(8) Kubeconfig 


O Token 


Kubeconfig YAML file * 


图 13-4 


13.2 配置 登录 权限 


Dashboard 支持 Kubeconfig 和 Token 两 种 认证 方式 ， 为 了 简化 配置 ， 我 们 通过 配置 文 
件 dashboard-admin.yaml 为 Dashboard 默认 用 户 赋予 admin 权限 ， 如 图 13-5 所 示 。 
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apiVersion: rbac.authorization.k8s.io/vlbetal 
kind: ClusterRoleBinding 
metadata 


name: 
labels 
k8s-app: kubernetes-dashboard 
roleRef 


kubernet 


es-dashboard 


apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 


пате: 


cluster- 


subjects 
kind: ServiceAccount 


пате : 


kubernet 


admin 


es-dashboard 


namespace: kube-system 





图 13-5 


执行 kubectl apply 使 之 生效 ， 如 图 13-6 所 示 。 


ubuntu@k8s-master:~$ 


ubuntuek8s-master: 


clusterrolebinding 
ubuntuek8s-master:-$ 


ubernetes-dashboard" 


$ kubectl apply -f dashboard-admin.yam| 
created 





图 13-6 


现在 直接 单 击 登录 页 面 中 的 SKIP 就 可 以 进入 Dashboard 了 ， 如 图 13-7 所 示 。 


kubernetes 


Cluster 
Namespaces 
Nodes 
Persistent Volumes 
Roles 


Storage Classes 


Namespace 


defaut = 


Overview. 


Workloads. 


Daemon Sets 
Deployments 

Jobs 

Pods 

Replica Sets 
Replication Controllers 


Stateful Sets 
Discovery and Load Balancing 


Ingresses 





Services. 
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Services 


Name Š 


© кете 


Secrets 


Name $ 


default-token-cx5x 


О, Search 


Overview 


abel 


component: apiserver 


provider: kubernetes. 


图 13-7 


Cluster I nternal endpoints 


kubernetes:443 TCP 


109601 kubernetes:0 ТСР 


Typ 


kubernetes.io/service-account-token 





Dashboard 界面 结构 


Dashboard 的 界面 很 简洁 ， 分 为 三 个 大 的 区 域 。 





(1) 项 部 操作 区 , 如 图 13-8 所 示 。 在 这 里 用 户 可 以 搜索 集群 中 的 资源 、 创 建 资源 或 退出 











©) kubernetes О, Search + силк | Q 





图 13-8 
(2) 左边 导航 菜单 。 通 过 导航 菜单 可 以 查看 和 管理 集群 中 的 各 种 资源 。 菜 单项 按照 资源 
的 层级 分 为 以 下 两 类 : 
€ Cluster 级 别 的 资源 ， 如 图 13-9 所 示 。 
€ Namespace 级 别 的 资源 ， 如 图 13-10 所 示 。 


默认 显示 的 是 default Namespace， 可 以 进行 切换 ， 如 图 13-11 所 示 。 





Namespace 


default 


Overview 


Workloads 
Daemon Sets 
Deployments 


Jobs 





Pods 


All namespaces 


Replica Sets 


Replication Controllers 












































Stateful Sets NAMESPACES 
Cluster Discovery and Load Balancing 
Namespaces iuret default 
Services 
Nodes 
Config and Storage А 
Persistent Volumes kube-public 
Config Maps 
pois Persistent Volume Claims 
Storage Classes pepe kube-system 
[ 13-9 图 13-10 图 13-11 
G) 中 间 主 体 区 。 
在 导航 菜单 中 单 击 了 某 类 资源 ， 中 间 主 体 区 就 会 显示 该 资源 所 有 实例 ， 比 如 单 击 Pods, 








如 图 13-12 所 示 。 
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Pods 

Name $ Node Status $ Restarts Age $ 
© kubemetes-dashboard-747c4f7cf-wwiz7 k8s-nodel Running ° 18 hours 
© nubeprowich7s k8s-node1 Running ° 18 hours 
© kubenanneids-f7wgk kBsnode1 Running ° 18 hours 
© aubenannerdsiniqt k8s-node2 Running o 18 hours 
© aubeproyecoo k8s-node2 Running ° 18 hours 
© kube-fannel-dsbgcix k8s master Running ° 18 hours 
© hube-apiseverkas master kesmaster Running ° 18 hours 
© beschedulerkesmaster k8s master Running ° 18 hours 
Ө etcdk8s-master k8s-master Running 0 18 hours 
© kube-controller-manager-k8s-maste k8s-master Running. 0 18 hours 
© kubedns-545bc4bfd4-6zrsw k&s master Running o 18hours 
© nubeproyaaem k8s-master Running ° 18 hours 

图 13-12 


典型 使 用 场景 


接 下 来 我 们 介绍 几 个 Dashboard 的 典型 使 用 场景 。 





13.4.1 部 署 Deployment 
单 击 项 部 操作 区 的 + CREATE 按钮 ， 如 图 13-13 所 示 。 





Deploy a Containerized App 
(8). Specify арр details below 


О Upload a YAML or JSON file 


0/24 


None = 


~ SHOW ADVANCED OPTIONS 


DEPLOY CANCEL 











图 13-13 
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用 户 可 以 直接 输入 要 部 署 应 用 的 名 字 、 镜 像 、 副 本 数 等 信息 ， 也 可 以 上 传 YAML 配置 文 
件 。 如 果 是 上 传 配置 文件 ， 则 可 以 创建 任意 类 型 的 资源 ， 而 不 仅仅 是 Deployment. 


13.4.2 在线 操 作 
对 于 每 种 资源 ， 都 可 以 单 





5 按钮 执行 各 种 操作 ， 如 图 13-14 所 示 。 





Deployments 
Name $ Namespace 


© kubemetesdashbosró — kubesystem 


© oes 


kube-system 


Labels s age 2 images 


Кёзарр: kubernetes das. 18 hours gctio/google. containers/k 
criorgoogle_contane 
gcrio/google.containe Scale 
gerio/google_containe 


kas-app: kube dns. 18hours 
Delete 


View/edit YAML| 





13-14 


例如 , 单 击 View/edit YAML, 可 直接 修改 资源 的 配置 , 保存 后 立即 生效 , 其 效果 与 kubectl 


edit 一 样 ， 如 图 13-15 所 示 。 



































Edit a Deployment 
1 
2 
3 
4 
5 name": "kube-dns", 
6 "namespace": "kube-systen", 
7 "selfLink": "/apis/extensions/vlbetal/namespaces/kube-system 
/deployments/kube-dns", 
8 "uid": "a676a020-c2c9-11e7-abb6-0800274451ad", 
$ "resourceVersion": "33294", 
10 "generation": 1, 
1% "creationTimestamp": "2017-11-06T08:08:192", 
12% "labels": 
13 "k8s-app": "kube-dns" 
14 }, 
15- "annotations": { 
16 "deployment.kubernetes.io/revision": "1" 
17 ) 
18 } 
19+ "врес": { 
20 "replicas": 1, 
21, "selector": { 
22” "matchLabels": { 
23 "k8s-app": "kube-dns" 
24 F 
25 P 
26+ "template" 
27* "metadata 
28 "creationTimestamp": null, 
29* "labels": ( 
CANCEL COPY UPDATE 








图 13-15 
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13.4.3 ”查看 资源 详细 信息 
某 个 资源 实例 的 名 字 , 可 以 查看 详细 信息 , 其 效果 与 kubectl describe 一 样 ,如 图 13-16 




















Details 


Name: kube dns 
Namespace: kube system 

Labels: k8s-app: kube-dns 

Selector: kgs-app: kube-dns 

Strategy: RollingUpdate 

Min ready seconds: 0 

Revision history limit: Not set 

Rolling update strategy: Max surge: 10% Max unavailable: 0 


Status: 1 updated, 1 total, 1 available, 0 unavailable 
Status 


New Replica Set 


Nam Namesp " 


GEHEN gerlo/google.conteiners/ 
© kubednssisbcibíd  kube-system in 18 hours getio/google containers 
podtemplate hash: 101 geio/google.containers/ 





Old Replica Sets 


ere is nothing to display here 








图 13-16 


1344 查看 Pod 日 志 


在 Pod 及 其 父 资源 (DaemonSet、ReplicaSet 等 ) 页 面 单 
志 ， 其 效果 与 kubectl logs 一 样 ， 如 图 13-17 所 示 。 





按钮 ， 可 以 查看 Pod 的 日 


Logs from kube-flannel 


I1186 98 


Node controller sync зис 
Created subnet manager: Kubernetes Subnet Man| 
651580 ignal hand 
k config - Backend Lype: vxlan 
VXLAN config 
659647 Wrote 
659/14 main.go:299] Runn 
659781 main.go:317] Waiting for all to exit 
n.network.go:56] watching for new subnet leases 





Logs from 11/6/17 8:09 AM to 11/6/1 








图 13-17 


Kubernetes Dashboard 界面 设计 友好 ， 自 解释 性 强 , 可 以 看 作 GUI 版 的 kubectl， 更 多 功 
能 留 给 大 家 自己 探索 。 
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13.5 小 结 


本 章 介 绍 了 Kubernetes Dashboard 的 安装 和 使 用 方法 。Dashboard 能 完成 日 常 管理 的 大 部 
分 工作 ， 可 以 作为 命令 行 工 具 kubectl 的 有 益 补充 。 
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第 14 章 


Kubernetes 集群 监控 





创建 Kubernetes 集群 并 部 署 容 器 化 应 


集群 一 起 都 是 正常 的 ， 


Kubernetes 是 一 个 复杂 系统 ， 运 


故障 排查 提供 及 时 和 准确 的 数据 支持 。 





Ж 




















一 步 。 一 旦 集群 运行 起 来 ， 我 们 需要 确保 
所 有 必要 组 件 就 位 并 各 司 其 职 ， 有 足够 的 资源 满足 应 用 的 需求 。 
维 团队 需要 有 一 套 工 具 帮 助 他 们 获知 集群 的 实时 状态 ， 并 为 




















Esa PH Kubernetes 常用 的 监控 方案 ， 下 一 章 会 讨论 日 志 管 理 。 


Weave Scope 


Weave Scope 是 Docker 和 Kubernetes 可 视 化 监控 工具 。Scope 提供 了 自 上 而 下 的 集群 
基础 设施 和 应 用 的 完整 视图 ， 用 户 可 以 轻松 对 分 布 式 的 容器 化 应 用 进行 实时 监控 和 问题 诊断 。 


14.1.1 安装 Scope 
安装 Scope 的 方法 很 简单 ， 执 行 如 下 命令 : 


kubectl apply --namespace kube-system -f 


"https://cloud.weave. 


了 з=. PT Ga 


works/k8s/scope.yaml?k8s-version-$ (kubectl version | base64 


部 署 成 功 后 ， 有 如 图 14-1 所 示 的 相关 组 件 。 


ubuntu@k8s-master 


NAME 
weave-scope-agent 
ubuntuek8s-maste 
ubuntuék8s-master 
NAME 
weave-scope-app 
ubuntuék8s-maste 


ubuntuek8s-master: 


NAME 
weave-scope-app 


ubuntuek8s-master: 


ubuntuék8s-maste 


weave-scope-agent- 
weave-scope-agent- 
weave-scope-agent- 


E 
ubuntuek8s-master : 


kubectl get --namespace-kube-system daemonset weave-scope-agen 
DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SEL 
3 3 3 3 3 <none> 
$ 


:~$ kubectl get --namespace-kube-system deployment weave-scope-app 


DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
1 1 1 1 18һ 
-$ 
kubectl get --namespace-kube-system service weave-scope-app 
ТҮРЕ CLUSTER- IP EXTERNAL-IP PORTCS) AGE 
NodePort 10.106.149.68 «none» 80:30693/TCP — 18h 
=$ 
~$ kubectl get --namespace=kube-system pod | grep weave 
765g2 2/1 Running 
nchjr 1/1 Running 
wnzn4 1/1 Running 


weave-scope-app-567cfdb6d5-kk2cg 1/1 Running 


ubuntu@k8s-master: 





~$ 


图 14-1 


(1) DaemonSet weave-scope-agent， 集 群 每 个 节点 上 都 会 运行 的 scope agent 程序 ， 负 责 


收集 数据 。 
(2) Deployment weave-scope-app，scope 应 用 ， 从 agent 获取 数据 ， 通 过 Web UI 展示 
并 与 用 户 交互 。 


(3) Service weave-scope-app， 默 认 是 ClusterIP 类 型 ， 为 了 方便 ， 已 通过 kubectl edit f£ 
改 为 NodePort。 


14.1.2 使 用 Scope 
浏览 器 访问 http://192.168.56.106:30693/，Scope 默认 显示 当前 所 有 的 Controller 
(Deployment, DaemonSet 等 ) ， 如 图 14-2 所 示 。 


өсө * 
ӘУ rm e 


€ © 192168.56л06:30893 © © search. 


4 weavescope Q SEARCH PROCESSES CONTAINERS — PODS ноте <GRAPH m TABLE 
mrave ovswE — CONIROUERS  weavener БЕРЕНЕ 
av mace services 
kube-dns kube-flannel-ds kube-proxy 


Deploymentof1pod — DaemonSetof3pods DaemonSet of 3 pods 


(2 ° 。 


kubernetes-dashboa.. weave-scope-agent weave-scope-app 
Deployment of 1 pod DaemonSet of 3 pods Deployment of 1 pod 


$ NODES (4 FILTERED) 
Sow unmanaged — Hide Unmanaged 


deluk  kubesystem Ali Namespaces VERSION 1.6.5 ON weave осоре 


图 14-2 


1. 拓扑 结构 
Scope 会 自动 构建 应 用 和 集群 的 逻辑 拓扑 ， 比 如 单 击 顶 部 PODS， 会 显示 所 有 Pod 以 及 
Pod 之 间 的 依赖 关系 ， 如 图 14-3 Pros. 
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每 天 5 分 钟 玩 转 Kubernetes 





sog Weave Scope x Vue 





Ф ) © 19216856106:30603/0/state/('controlPipe"-null; nodeDetails":)topologyViewMode""topo""pinnedMetricType"null"pinnedSear | Œ | Q Search 
[© — 






































4£ weavescope а SEARCH PROCESSES = CONTAINERS PODS HOSTS. MGRAPH STABLE 
вушмє FYDNSNAME CONTROLLERS  WEAVENET у ) 
вүмсе savces 





[ama вагона ВИЙ i 
图 14-3 


单 击 HOSTS， 会 显示 各 个 节点 之 间 的 关系 ， 如 图 14-4 所 示 。 


PROCESSES CONTAINERS PODS HOSTS 
BY NAME BY DNS МАМЕ CONTROLLERS WEAVE NET 
BY IMAGE SERVICES 
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2. 实时 资源 监控 
可 以 在 Scope 中 查看 资源 的 CPU 和 内 存 使 用 情况 ， 如 图 14-5 所 示 。 
支持 的 资源 有 Host、Pod 和 Container， 如 图 14-6、 图 14-7 所 示 。 


783.3М8 


k8s-master 


353.5MB 
-DDn 
k8s-node 


Y 


4707MB 
чш» 
k8s-node2 


y 


C) 


CPU Memory The мете! 


Outbound connections 


图 14-5 


0.33% 


4 
etcd-k8s-master 


1 container k Š 


0.69% 


kube-apiserver- 
k8s-master 
1 container 





图 14-6 





图 14-7 


3. 在 线 操作 


Scope 还 提供 了 便捷 的 在 线 操作 功能 ， 比 如 选中 某 个 Host, "id 


览 器 中 打 














节点 的 命令 行 终端 ， 如 图 14-8 所 示 。 





H 


> 按钮 可 以 直接 在 浏 
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QV JÆ weave scope -kas-master 


19216855106 


fr weavescope а sus 








图 14-8 


单 击 Deployment 的 + 可 以 执行 Scale Up 操作 ， 如 图 14-9 所 示 。 


kubernetes-dashboard 





TYPE Deployment 
AcE kube-system 
» 3 days ago 








sTRATEcY RollingUpdate 





kubernetes-dashbo.. Running 1 1024423 


kubernetes-dashboard 0.00% 33.4МВ 











200: — nnns оома 











图 14-9 








查看 Pod 的 日 志 ， 如 图 14-10 所 示 。 


masus 075 


44098generic#121-Ubuntu SMP Tu. 
10013m40s 





2 
15 
n" 
5 








° /# w 


| weavescope 









Q зем 











Pons 








І 14-10 


Running 
P: 192.168.56.105 

kubesystem 

3 days ago 











可 以 查看 attach. restart, stop 容器 ， 以 及 直接 在 Scope 中 排查 问题 ， 如 图 14-11 所 示 。 

















28 MB 


MEMORY 


jcrio/google_containers/k8s-dns-kub. 


kube-dns -domain=cluster.local. —dn. 
Up 19 hours 


9h42m55s 





/Kube-dns 


е CPU MEMORY 


3613 0.00% 22.3 MB 














14-11 
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4. 强大 的 搜索 功能 


Scope 支持 关键 字 搜 索 和 定位 资源 ， 如 图 14-12 所 示 。 还 可 以 进行 条 件 搜索 ， 比 如 查找 和 
定位 MEMORY 大 于 100MB 的 Pod， 如 图 14-13 所 示 。 























| Q prox PROCESSES CONTAINERS PODS HOSTS < GRAPH ЕВ TABLE 
Des sr M E BY NAME BY DNS NAME CONTROLLERS WEAVE NET CPUX Memory 
enter to apply the search as а BY IMAGE SERVICES 
filter. Ө 
. . . 
-—— 
mura 
图 14-12 
| О, MEMORY > 100M PROCESSES CONTAINERS PODS | HOSTS 
Try "еїс@-К8з-таз', ВҮ МАМЕ BY DNS NAME CONTROLLERS | WEAVE NET 
"state:running", or "cpu > 2%". Hit = 
enter to apply the search as а RIMAGE [Le | 
filter. Ө 
1027M8 
weave-scope- 
agent 76562 
1 contaber 
a. 
24 мв 
一 
kube-apiserver-kBs-.. 
1corlainer 
. 
etcd-k8s-master. 
Tane 
图 14-13 


Weave Scope 界面 极其 友好 ， 操 作 简洁 流畅 ， 更 多 功能 留 给 大 家 去 探索 。 
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Heapster 


Heapster 是 Kubernetes 原生 的 集群 监控 方案 。Heapster 以 Pod 的 形式 运行 ， 它 会 自动 
ЕТА, АЛА Б Kubelet 获取 监控 数据 。Kubelet 则 是 从 节点 上 的 cAdvisor 收 














发 现 
数据 。 

Heapster 将 数据 按照 Pod 进行 分 组 , 将 它们 存储 到 预先 配置 的 backend 并 进行 可 视 化 展 
示 。Heapster 当前 支持 的 backend 有 InfluxDB( 通 过 Grafana 展示 )、Google Cloud Monitoring 
等 。Heapster 的 整体 架构 如 图 14-14 所 示 。 

















图 14-14 


下 面 我 们 将 实践 由 Heapster.InfluxDB 和 Grafana 组 成 的 监控 方案 .Kubelet 和 cAdvisor 
是 Kubernetes 的 自 带 组 件 ， 无 须 额 外 部 署 。 


14.2.1 部 署 
Heapster 本 身 是 一 个 Kubernetes 应 用 ， 部 署 方法 很 简单 ， 运 行 如 下 命令 : 


git clone https://github.com/kubernetes/heapster.git 
kubectl apply -f heapster/deploy/kube-config/influxdb/ 
kubectl apply -f heapster/deploy/kube-config/rbac/heapster-rbac.yaml 


Heapster 相关 资源 如 图 14-15 所 示 。 


ubuntu&k8s-master: -$ 
ubuntufk8s-master:-$ kubectl get --nomespace-kube-system deployment | grep -e heopster -e monitor 

hea 8m 

monitoring-grafana 

monitoring-influxdb 

ubuntu8k8s-mastei 

ubuntuek8s-master:-$ kube: - kube-sys ce -e heapster -e moni 

heapster о / 

moni toring-graf. E S: 14/TCP 

monitoring 

ubuntu@k8s-maste 

ubuntu&k8s-maste е потез tem pod -о wide | grep -e heapster -e monitor 
heapster-5d67855584-5hdqn Running @ 8т k8s-node2 
moni toring-grafana-Sbccc9£786- / Running 0 8m 3 k8s-n 
monitoring-influxdb-85cb4985d4 / Running © 8m 4 k8s-n 
ubuntu&k8s-master:-$ 





图 14-15 
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为 了 便于 访问 ， 已 通过 kubectl edit 将 Service monitoring-grafana 的 类 型 修改 为 
NodePort. 


14.242. ”使 用 


浏览 器 打开 Grafana 的 Web UI: http://192.168.56.105:32314/。 
Heapster 已 经 预先 配置 好 了 Grafana 的 DataSource 和 Dashboard， 如 图 14-16 所 示 。 

















є 192.168.56.105: 


Home Dashboard 





图 14-16 


单 击 左上 角 的 Home 菜单 , 可 以 看 到 预定 义 的 Dashboard Cluster 和 Pods, 如 图 14-17 
所 示 。 


(9 ` Q Find dashboards by name 


| $ Home 


| a2 Cluster 


器 Pods 





图 14-17 





单 击 Cluster， 可 以 查看 集群 中 节点 的 CPU、 内 存 、 网 络 和 磁盘 的 使 用 情况 ， 如 图 14-18 
所 示 。 
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Grafana - Cluster 


€ © 19216856105 е 


49- @ Cluster - 


odename ^ kBs-master ~ 


Overall Cluster CPU Usage 


0934 0936 0938 09:40 09 09:44 09:46 09:48 


— Usage k8s-master — Usage К8з-побеї 一 Usage k8s-node2 — Limit k8s-master — Limit k8s-node1 == Limit kBs-node2 


Individual CPU Usage: k8s-master 





图 14-18 
在 左上 角 可 以 切换 查看 不 同 节点 的 数据 ， 如 图 14-19 所 示 。 


(9 ВЕ Cluster- © 


nodename 


k8s-master 


1.0K k8s-node1 


800 — k8s-node2 





图 14-19 


切换 到 Pods Dashboard， 可 以 查看 Pod 的 监控 数据 ， 包 括 单个 Pod 的 CPU、 内 存 、 网 
络 和 磁盘 使 用 情况 ， 如 图 14-20 所 示 。 
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Grafana - Pods 


namespace 。 kubesystem- — podname — etcd-k8s-master + 


Individual CPU Usage: kube-system etcd-k8s-master 


0934 0936 0938 0940 0942 0524 09:46 ола 

— Usage kübe-system etcd-kBs-master екс — Limit kube-system etcd-k8s-master etcd 一 Request kube-system etcd-k8s- 

Individual Memory Usage: kube-system etcd-kBs-master 

EI 
D 
143 MB 
95 ib 
ss mB 

oB 

rp o3 0938 0940 0942 09:4 0946 r7 P 0952 


~ Usage kube-system etcd-k8s-master etcd == Limit kube-system etcd-k8s-master etcd 一 Request kube-system etcd-k8s-master etcd Working Set 


Individual Network Usage: kube-system etcd-k8s-master 
100kBps 


a0kBps 
60 kBps 


40 kBps 





图 14-20 
在 左上 角 可 以 切换 到 不 同 Namespace 的 Pod， 如 图 14-21 所 示 。 
QQ Врв. е в o 


е  Kubesstem- робпате | 


etcd-k8s-master 
heapster-5d67855584-5hdqn 
kube-apiserver-k8s-master 
kube-controller-manager-k8s-master 
Jube-dns-545bc4bfd4-jzh4c 
kube-fiannel-ds-bgclx 
kube-fiannel-ds-f7wgk 


= kube-fiannel-ds-Injat 


kube-proxy-9cggh 
kube-proxy-jch75 
р kube-proxy-q6j8m 


kube-scheduler-k8s-master 
191 мв 
kubernetes-dashboard-747c4f7cf-wwlz7 
143MiB 





monitoring-grafana-Sbccc9f786-Sbbkw 


图 1421 


Heapster 预定 义 的 Dashboard 很 直观 ， 也 很 简单 。 如 有 必要 ， 可 以 在 Grafana 中 定义 自己 
的 Dashboard， 满 足 特定 的 业务 需求 。 
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Prometheus Operator 


前 面 我 们 介绍 了 Kubernetes 的 两 种 监控 方案 , BI Weave Scope 和 Heapster， 它 们 主要 的 
监控 对 象 是 Node 和 Pod。 这 些 数据 对 Kubernetes 运 维 人 员 是 必需 的 ， 但 还 不 够 。 我 们 通常 
还 希望 监控 集群 本 身 的 运行 状态 ， 比 如 Kubernetes 的 API Server. Scheduler. Controller 
Manager 等 管理 组 件 是 否 正常 工作 以 及 负荷 是 否 过 大 等 。 

本 节 我 们 将 学 习 监控 方案 Prometheus Operator， 它 能 回答 上 面 这 些 问题 。 

Prometheus Operator 是 CoreOS 开发 的 基于 Prometheus 的 Kubernetes 监控 方案 ， 也 可 
能 是 目前 功能 最 全 面 的 开源 方案 。 我们 先 通 过 截图 了 解 一 下 它 能 干什么 。 

Prometheus Operator 通过 Grafana 展示 监控 数据 ， 预 定义 了 一 系列 的 Dashboard， 如 图 


14-22 所 示 。 


Q 











Find dashboards by name 


Home 

Deployment 

Kubernetes Capacity Planning 
Kubernetes Cluster Health 
Kubernetes Cluster Status 
Kubernetes Control Plane Status 
Kubernetes Resource Requests 
Nodes 


Pods 





图 14-22 


€  Kubernetes 集群 的 整体 健康 状态 如 图 14-23 所 示 。 


Everything UP and 


healthy 





图 1423 
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ө 整个 集群 的 资源 使 用 情况 如 图 14-24、 图 14-25 所 示 。 


(Q-  BliKubernetes Capacity PI 





图 14-25 


€  Kubernetes 各 个 管理 组 件 的 状态 如 图 14-26, A 14-27 所 示 。 





图 14-26 
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器 Kubernetes Control Plane Status - в > eumnsmnum С 


AP Servers up API Server Request Error Rate 


p AP Server Request Rates 





Ё 14-27 
ө 节点 的 资源 使 用 情况 如 图 14-28 所 示 。 


09 - 88 Nodes - 


192.168.56.107:9100 
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Memory Usage. 
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— memory used ~ memory buffers — memory cached — memory free 


Disk vo 
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ов 1030 1032 1034 1036 1038 1040 1042 10 1046 1048 1050 10:52 


一 cnio — docker0 — enp0s3 — enp0s8 一 enp0s9 — flannel1 —vethofd4SedO — vethbde1df37 — vethc0798465 一 vethd65efsal 一 vethda48a512 
vethde900847 。 virbr0 — virbrO-nic 





Ë 14-28 (а) 
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图 14-28 (b) 
€ Deployment 的 运行 状态 如 图 14-29 所 示 。 


45 - EB Deployment - 
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navallable — updated 





158 


€ Pod 的 运行 状态 如 图 14-30 所 示 。 


49- Hros. w e B © 


Namespace АШ - Pod 。 weave-scope-app-567cfdb6d5-kk2cg ~ Container — All- 


129 MiB 
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图 14-30 











这 些 Dashboard 展示 了 从 集群 到 Pod 的 运行 状况 ， 能 够 帮助 用 户 更 好 地 运 维 
Kubernetes， 而 且 Prometheus Operator 迭代 非常 快 ， 相 信 会 继续 开发 出 更 多 更 好 的 功能 ， 所 
以 值得 我 们 花 些 时 间 学 习 和 实践 。 











14.3.1 Prometheus 架构 


因为 Prometheus Operator 是 基于 Prometheus 的 ,所 以 我 们 需要 先 了 解 一 下 Prometheus。 

Prometheus 是 一 个 非常 优秀 的 监控 工具 。 准 确 地 说 应 该 是 监控 方案 。Prometheus 提供 了 
数据 搜集 、 存 储 、 处 理 、 可 视 化 和 告警 一 套 完整 的 解决 方案 。Prometheus 的 架构 如 图 14-31 
所 示 。 








T 
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图 14-31 


宫 网 上 的 原始 架构 图 比 上 面 这 张 要 复杂 一 些 , 为 了 避免 注意 力 分 散 , 这 里 只 保留 了 最 重要 
的 组 件 。 





1. Prometheus Server 

Prometheus Server 负责 从 Exporter 拉 取 和 存储 监控 数据 ， 并 提供 一 套 灵活 的 查询 语言 
(PromQL) 供用 户 使 用 。 

2. Exporter 

Exporter 负责 收集 目标 对 象 (host、container 等 ) 的 性 能 数据 ， 并 通过 HTTP 接口 供 
Prometheus Server 获取 。 

3. 可 视 化 组 件 

监控 数据 的 可 视 化 展现 对 于 监控 方案 至 关 重 要 。 以 前 Prometheus 自己 开发 了 一 套 工具 ， 
不 过 后 来 废弃 了 ， 因 为 开源 社区 出 现 了 更 为 优秀 的 产品 Grafana。Grafana 能 够 与 Prometheus 
无 缝 集成， 提供 完美 的 数据 展示 能 力 。 























4. Alertmanager 
日 户 可 以 定义 基于 监控 数据 的 告警 规则 ， 规 则 会 触发 告警 。 一 旦 Alermanager 收 到 告警 ， 
就 会 通过 预定 义 的 方式 发 出 告警 通知 ， 支 持 的 方式 包括 Email、PagerDuty、Webhook 等 。 
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第 14 章 Kubernetes 集群 监控 


14.3.2. Prometheus Operator 架构 


Prometheus Operator 的 目标 是 尽 可 能 简化 在 Kubernetes 中 部 署 和 维护 Prometheus 的 工 
作 。 其 架构 如 图 14-32 所 示 。 


— 


busua т № 
d ^ 
i ServiceMonitor 2 $g 


Service 5 


| 


c» 
Operator ans г. Server 


deploy 
图 14-32 
图 14-32 中 的 每 一 个 对 象 都 是 Kubernetes 中 运行 的 资源 。 
1. Operator 


Operator 即 Prometheus Operator， 在 Kubernetes 中 以 Deployment 运行 。 其 职责 是 部 署 
和 管理 Prometheus Server， 根 据 ServiceMonitor 动态 更 新 Prometheus Server 的 监控 对 象 。 





2. Prometheus Server 

Prometheus Server 会 作为 Kubernetes 应 用 部 署 到 集群 中 。 为 了 更 好 地 在 Kubernetes 中 
管理 Prometheus, CoreOS 的 开发 人 员 专 门 定义 了 一 个 命名 为 Prometheus 类 型 的 Kubernetes 
定制 化 资源 。 我 们 可 以 把 Prometheus 看 作 一 种 特殊 的 Deployment， 它 的 用 途 就 是 专门 部 署 


Prometheus Server。 





3. Service 

这 里 的 Service 就 是 Cluster 中 的 Service 资源 ， 也 是 Prometheus 要 监控 的 对 象 ， 在 
Prometheus 中 叫 作 Target。 每 个 监控 对 象 都 有 一 个 对 应 的 Service。 比 如 要 监控 Kubernetes 
Scheduler， 就 得 有 一 个 与 Scheduler 对 应 的 Service。 当 然 ，Kubernetes 集群 默认 是 没有 这 个 
Service 的 ，Prometheus Operator 会 负责 创建 。 
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4. ServiceMonitor 

Operator 能 够 动态 更 新 Prometheus 的 Target 列表 ，ServiceMonitor 就 是 Target 的 抽 
象 。 比 如 想 监 控 Kubernetes Scheduler， 用 户 可 以 创建 一 个 与 Scheduler Service 相映 射 的 
ServiceMonitor 对 象 。Operator 则 会 发 现 这 个 新 的 ServiceMonitor， 并 将 Scheduler 的 Target 
添加 到 Prometheus 的 监控 列表 中 。 

ServiceMonitor 也 是 Prometheus Operator 专门 开发 的 一 种 Kubernetes 定制 化 资源 类 型 。 




















5. Alertmanager 

除了 Prometheus 和 ServiceMonitor, Alertmanager 是 Operator 开发 的 第 三 种 
Kubernetes 定制 化 资源 。 我 们 可 以 把 Alertmanager 看 作 一 种 特殊 的 Deployment, 它 的 用 途 就 
是 专门 部 署 Alertmanager 组 件 。 


14.3.3 部署 Prometheus Operator 

笔者 在 实践 时 使 用 的 是 Prometheus Operator 最 新 版 本 v0.14.0。 由 于 项 目 开发 迭代 速度 
很 快 ， 部 署 方法 可 能 会 更 新 ， 必 要 时 请 参考 官方 文档 。 

1. 下 载 最 新 源码 


git clone https://github.com/coreos/prometheus-operator.git 

















cd prometheus-operator 

为 方便 管理 , 创建 一 个 单独 的 Namespace monitoring, Prometheus Operator 相关 的 组 件 都 
会 部 署 到 这 个 Namespace。 

kubectl create namespace monitoring 

2. 安装 Prometheus Operator Deployment 


helm install --name prometheus-operator --set rbacEnable-true 
--namespace-monitoring helm/prometheus-operator 


Prometheus Operator 所 有 的 组 件 都 打包 成 Helm Chart， 安 装 部 署 非常 方便 ， 如 图 14-33 
所 示 。 如 果 对 Helm 不 熟悉 ， 可 以 参考 前 面相 关 的 章节 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl get --namespace=monitoring deployment prometheus-operator| 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 


prometheus-operator-prometheus-operator ab 1 ak 1 
ubuntuek8s-master: -$ 





图 14-33 


3. 安装 Prometheus, Alertmanager 和 Grafana 


helm install --name prometheus --set serviceMonitorsSelector.app-prometheus 
--set ruleSelector.app-prometheus --namespace-monitoring helm/prometheus 


helm install --name alertmanager --namespace-monitoring helm/alertmanager 
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helm install --name grafana --namespace-monitoring helm/grafana 


可 以 通过 kubectl get prometheus 查看 Prometheus 类 型 的 资源 ， 如 图 14-34 所 示 。 


ubuntuék8s-master :~$ 

ubuntuék8s-master:-$ kubectl get --namespacesmonitoring prometheus 

МАМЕ AGE 

prometheus 1d 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring pod prometheus-prometheus-0 


NAME READY STATUS RESTARTS AGE 

prometheus-prometheus-0 2/2 Running 0 1d 

ubuntue@k8s-master:~$ 

ubuntuék8s-master:-$ kubectl get --namespace-monitoring service prometheus-prometheus 
INAME TYPE CLUSTER-IP EXTERNAL-IP — PORT(S) AGE 
prometheus-prometheus ^ NodePort 10.96.207.169 <none> 9090:30413/TCP 1d 
ubuntu@k8s-master:~$ 





图 14-34 


为 了 方便 访问 Prometheus Server， 这 里 已 经 将 Service 类 型 通过 kubectl edit 改 为 
NodePort. 
同样 可 以 查看 Alertmanager 和 Grafana 的 相关 资源 ， 如 图 14-35. E 14-36 所 示 。 


iubuntuek8s -master:-$ 
:~$ kubectl get --namespace-monitoring alertmanager 


alertmanager 24 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-monitoring pod alertmanager-alertmanager-0 
INAME READY STATUS RESTARTS AGE 
lalertmanager-alertmanager-0 2/2 Running 0 2d 

lubuntu&k8s-master:-$ 

ubuntu@k8s-moster:-$ kubectl get --namespace-monitoring service alertmanager-alertmanager 
NAME ТҮРЕ CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
alertmanager-alertmanager NodePort 10.103.53.199 <none> 9093:32758/TCP 24 
ubuntuek8s-master: -$ 





图 14-35 


ubuntuek8s master: -$ 

ubuntu&k8s-master:-$ kubectl get --namespace-monitoring deployment grafana-grafana 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

grafana-grafana 1 1 1 1 5h 

ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get --namespace-monitoring pod grafana-grafana-Sfdf676c68-v7dlb 
NAME READY STATUS RESTARTS АСЕ 


grafana-grafana-Sfdf676c68-v7dlb 2/2 Running 0 Sh 
ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring service grafana-grafana 
NAME ТҮРЕ CLUSTER-IP EXTERNAL-IP — PORTCS) AGE 
grafana-grafana ^ NodePort 10.109.107.156 <none> 80:32342/TCP — 5h 
ubuntuék8s-master:-$ 





图 14-36 
Service 类 型 也 都 已 经 改 为 NodePort。 
4. 安装 kube-prometheus 


kube-prometheus 是 一 个 Helm Chart， 打 包 了 监控 Kubernetes 需要 的 所 有 Exporter 和 
ServiceMonitor。 


helm install --name kube-prometheus --namespace-monitoring 
helm/kube-prometheus 
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每 个 Exporter 会 对 应 一 个 Service， 为 Pormetheus 提供 Kubernetes 集群 的 各 类 监控 数 
据 ， 如 图 14-37 所 示 。 


ubuntuek8s-master:-$ 
wbuntuékSs-master:-$ kubectl get --oll-nomespac 
NAMESPACE МАМЕ CLUSTER-IP EXTERNAL-IP 
default kubernetes Cluste 1 «none» 
kube-system — heapster 
kube-dns ClusterIP 
kube-prometheus exporter kube api ClusterIP 
kube-system ^ kube-prometheus-exporter-kube-controller-mano; ClusterIP 
kube-system kube-prometheus-exporter-kube-dns ClusterIP 
kube-prometheus-exporter-kube- ClusterIP «none» 4001/TCP 
kube-pronetheus-exporter-kube ° ClusterIP «none» 10251/TCP 
kubelet — ` ClusterIP ione» 10250/ТСР 
kubernetes-dashboard NodePort <none> 
monitoring-grafana o 10.111.8 <none> 
kube-system monitoring-influxdb C 10.99.44.147 «попе» 
kube-system — tiller-deploy ClusterIP 10.111.247.7 — «none» 
kube-system — weave-scope-app NodePort 10.106.149.68 
monitoring alertmanager-alertmanager NodePort 10.103.53.199 
monitoring ^ alertmonager-operated Clus Non 
monitoring ^ grafona-grafana 10.109.107.156 80:32342/1CP 
o е 10.100.157.79 80/TCP 
5.108.197 < 9100/TCP 
WOnTEOFing — ClusterIP <none> 9090/TCP 
monitoring promethei ethe NodePort 207.169 < 9090:30413/7d 





图 14-37 


每 个 Service 对 应 一 个 ServiceMonitor， 组 成 Pormetheus 的 Target 列表 ， 如 图 14-38 
所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring servicemonitor 
NAME AGE 
alertmanager-alertmanager 2d 
kube-prometheus-exporter-kube-api 2d 
kube-prometheus-exporter-kube-controller-manager 2d 
kube-prometheus-exporter-kube-dns 2d 
kube-prometheus-exporter-kube-etcd 2d 
kube-prometheus-exporter-kube-scheduler 2d 
kube-prometheus-exporter-kube-state 2d 
kube-prometheus-exporter-kubelets 2d 
kube-prometheus-exporter-kubernetes 2d 
kube-prometheus-exporter-node 2d 
prometheus-operator 2d 
prometheus-prometheus 1d 
ubuntuék8s-master:-$ 





图 14-38 


与 Prometheus Operator 相关 的 所 有 Pod 如 图 14-39 所 示 。 


ubuntuek8s-master:-$ 
ubuntuk8s-master:-$ kubectl get pods --namespace-monitoring -o wide 

NAME READ’ STATUS RESTARTS 
alertmanager-alertmanager-0 Running 
grafana-grafana-5fdf676c68-v7dlb 2 Running 
kube-prometheus-exporter-kube-state-5ff8596 p 2 Running 


kube-prometheus-exporter-node-6hbj7 Running 2 9 k8s-node1 
kube-prometheus-exporter-node-k59dm / Running 9. ў k8s-node2 
kube-prometheus-exporter-node-t4cns ⁄ Running 92.16 1 k8s-master 
prometheus-operator-prometheus-operator-597f678b79-94qvw Rumning k8s-node1 
prometheus-prometheus-Q f Running k8s-node1 
ubuntuêk8s-master :~$ 





图 14-39 


我 们 注意 到 有 些 Exporter 没有 运行 Pod, 这 是 因为 像 API Server, Scheduler, Kubelet 等 
Kubernetes 内 部 组 件 原生 就 支持 Prometheus， 只 需要 定义 Service 就 能 直接 从 预定 义 端 口 获 
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通过 浏览 器 打开 Pormetheus 的 Web UI Chttp://192.168.56.105:30413/targets) ， 如 图 14-40 
所 示 。 




















C © 192.168.56.105:3 


3/targets 





[Targets 


alertmanager 


Endpoint State Labels 


http://10.244.1.26:9093/metrios ШРЫ ЕЕ rr 


kube-prometheus-exporter-kube-dns 


Endpoint State Labels. 

htp/J10244.12110094mercs ШР IC rr r rra 
EXUNUITITUISIUIUUETE 

hüpiAO244.2U10095/metics (ШР [тезтез отто CR осе каз ө з 


kube-prometheus-exporter-kube-state 


Endpoint State Labels 


htüp//10244231:8080/mencs — UP — EITTTTETTTETTETITTR rara rz; 


kube-prometheus-exporter-node 














Endpoint State. Labels. 
htpV192.168.56.1059100menics ШР r> 
htp//92.16856.1069100/m$etics (ШР 


图 14-40 
可 以 看 到 所 有 Target 的 状态 都 是 UP。 
5. 安装 Alert 规则 
Prometheus Operator 提供 了 默认 的 Alertmanager 告警 规则 ， 通 过 如 下 命令 安装 。 


sed -ie 's/role: prometheus-rulefiles/app: prometheus/g' 
contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 
sed -ie 's/prometheus: k8s/prometheus: prometheus/g' 
contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 
sed -ie 
's/job-N"kube-controller-manager/job-N"kube-prometheus-exporter-kube-controlle 
r-manager/g' 
contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 
sed -ie 's/job-WM"apiserver/job-WMV"kube-prometheus-exporter-kube-api/g"' 
contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 
sed -ie 


's/job-N"kube-scheduler/job-V"kube-prometheus-exporter-kube-scheduler/g' 
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contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


sed -ie 's/job-WX"node-exporter/job-V"kube-prometheus-exporter-node/g' 


contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


kubectl apply -n monitoring -f 


contrib/kube-prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


6. 安装 Grafana Dashboard 


Prometheus Operator 定义 了 显示 监控 数据 的 默认 Dashboard， 通 过 如 下 命令 安装 。 


sed -ie 's/grafana-dashboards-0/grafana-grafana/g' 


contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml 


sed -ie 's/prometheus-k8s.monitoring/prometheus-prometheus.monitoring/g' 


contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml 


kubectl apply -n monitoring -f 


contrib/kube-prometheus/manifests/grafana/grafana-dashboards.yaml 


打开 Grafana 的 Web UI (http://192.168.56.105:32342/) ， 如 图 14-41 所 示 。 


H- 8 Home- % 


Pods 
Deployment 
Nodes 


Kubernetes Control Plane Status 


图 14-41 


Grafana 的 DataSource 和 Dashboard C AJME, Hi 
论 过 的 那些 Dashboard 了 ， 如 图 14-42 所 示 。 
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Home Dashboard 





Ir Home 就 可 以 使 用 我 们 在 
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Find dashboards by пате Y starred | tags 


Home 
Deployment 
Kubernetes Capacity Planning 
Kubernetes Cluster Health 
Kubernetes Cluster Status 
Е: Kubernetes Control Plane Status 
Kubernetes Resource Requests 
器 Nodes 


器 Pods 





图 14-42 





本 章 我 们 实践 了 三 种 Kubernetes 监控 方案 。 

(1) Weave Scope 可 以 展示 集群 和 应 用 的 完整 视图 。 其 出 色 的 交互 性 让 用 户 能 够 轻松 对 
容器 化 应 用 进行 实时 监控 和 问题 诊断 。 

(2) Heapster 是 Kubernetes 原生 的 集群 监控 方案 。 预 定义 的 Dashboard 能 够 从 Cluster 
和 Pods 两 个 层次 监控 Kubernetes。 

(3) Prometheus Operator 可 能 是 目前 功能 最 全 面 的 Kubernetes 开源 监控 方案 。 除 了 能 
够 监控 Node 和 Pod， 还 支持 集群 的 各 种 管理 组 件 ， 比 如 API Server、Scheduler、Controller 


Manager 等 。 


Kubernetes 监控 是 一 个 快速 发 展 的 领域 ， 随 着 Kubernetes 的 普及 ， 一 定 会 涌现 出 更 多 的 
优秀 方案 。 
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第 15 = 
Kubernetes 集群 日 志 管 理 


Kubernetes 开发 了 一 个 Elasticsearch 附加 组 件 来 实现 集群 的 日 志 管 理 。 这 是 
Elasticsearch, Fluentd 和 Kibana 的 组 合 。Elasticsearch 是 一 个 搜索 引擎 ， 负 责 存储 日 志 并 提 
供 查询 接口 ，Fluentd 负责 从 Kubernetes 搜集 日 志 并 发 送 给 Elasticsearch; Kibana 提供 了 
个 Web GUI， 用 户 可 以 浏览 和 搜索 存储 在 Elasticsearch 中 的 日 志 ， 如 图 15-1 所 示 。 


-э-=- Е 
b. 4 


kubernetes fluentd 











部 署 


Elasticsearch 附加 组 件 本 身 会 作为 Kubernetes 的 应 用 在 集群 里 运行 ， 其 YAML 配置 文 
件 可 从 https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd-elasticsearch 
获取 ， 如 图 15-2 所 示 。 





master»  kubernetes / cluster / addons / fluentd-elasticsearch / 


kBs-merge-robot Merge pull request #55509 from taliclair/psp-addons = u 


lit es-image search logging. discovery 









lin fluentd-es-image 
lis podsecuritypolicies 
OWNERS 


README.md d the fluentd configuratio. 





es-service.yaml n templates 


es-statefulset.yaml arch Docker image tag 
fluentd-es-configmap.yaml 


fluentd-es-ds.yaml 


kibana-deployment.yaml flue 















kiba templates 





-ѕегуісеуаті Adds the ne 








图 15-2 





可 将 这 些 YAML 文件 下 载 到 本 地 目录 ， 比 如 addons ， 通 过 kubectl apply -faddons/ 部 





署 ， 如 图 15-3 所 示 。 


ubuntuek8s-master:-$ 


ubuntuek8s-master:-$ kubectl apply -f addons/ 
service "elasticsearch-logging" created 
serviceaccount "elasticsearch-logging" created 
clusterrole "elasticsearch-logging" created 
clusterrolebinding "elasticsearch-logging" created 
statefulset "elasticsearch-logging" created 
configmap "fluentd-es-config-v0.1.1" created 


Serviceaccount "fluentd-es" created 
" created 


clusterrole "fluentd-e 


clusterrolebinding "fluentd-es" created 
daemonset "fluentd-es-v2.0.2" created 


deployment "kibana-loggin 


ubuntuek8s-master: -$ 


图 15-3 


这 里 有 一 点 需要 注意 : 后 面 我 们 会 通过 


created 
service "kibana-logging" created 





NodePort 访问 Kibana， 需 要 注释 掉 


kibana-deployment.yaml 中 的 环境 变量 SERVER_BASEPATH, 否则 无 法 访问 , 如 图 15-4 所 示 。 


spec: 
containers 
пате: kibana-logging 


image: docker.elastic.co/kibana/kibana: 


resources 


limits 
сри: 1000m 
requests 
сри: 10дт 
епу 
пате: ELASTICSEARCH_URL 
value: http://elasticsearch-lo 


name 
value 
name: XPACK_SECURITY_ENABLED 
value 

ports: 

- containerPort 

name: ui 

protocol: TCP 


图 15-4 


所 有 的 资源 都 部 署 在 kube-system Namespace 











如 图 15-5 所 示 。 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system daemonset fluentd-es-v2.0.2 


NAME DESIRED CURRENT READY 


ubuntuék8s -master:-$ 


UP-TO-DATE 
fluentd-es-v2.0.2 2 2 e z 


AVAILABLE NODE SELECTOR AGE 
2 <попе> E 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system pod -l "k8s-app-fluentd-es" 


NAME READY STATUS 


fluentd-es-v2.0.2-2hjp4 1⁄1 
fluentd-es-v2.0.2-m4gq7 1/1 
ubuntuék8s-master:-$ 


Running 0 
Running 0 


图 15-5 


RESTARTS 





AGE 
эт 
9m 
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DaemonSet fluentd-es 从 每 个 节点 收集 日 志 ， 然 后 发 送 给 Elasticsearch， 如 图 15-6 所 示 。 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system statefulset elasticsearch-logging 
NAME DESIRED CURRENT AGE 

elasticsearch-logging 2 2 13m 

ubuntuek8s-master: —$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system pod -l "k8s-app-elasticsearch-logging" 
NAME READY STATUS RESTARTS AGE 


elasticsearch-logging-0 1/1 Running 0 13m 

elasticsearch-logging-1 1/1 Running 0 13m 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system service elasticsearch-logging 
НАМЕ ТҮРЕ CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
elasticsearch-logging ^ NodePort 10.103.27.59 <none> 9200:32607/TCP 14m 
ubuntuék8s-master:-$ 





图 15-6 


Elasticsearch 以 StatefulSet 资源 运行 ， 并 通过 Service elasticsearch-logging 对 外 提供 接 
口 。 这 里 已 经 将 Service 的 类 型 通过 kubectl edit 修改 为 NodePort。 
可 通过 http://192.168.56.106:32607/ 验证 Elasticsearch 已 正常 工作 ， 如 图 15-7 所 示 。 











Ж C © 192.168.56.106:32607 


{ 
"name" : "elasticsearch-logging-1", 
"cluster папе" : "kubernetes-logging", 
"cluster uuid" : "wRgkHHpNRGCtyQoSvpAIjA", 
"version" : ( 
"number" : "5.6.2", 
"build hash" : "57e20f3", 
"build date" : "2017-09-23713:16:45.7032", 
"build snapshot" : false, 
"lucene version" : "6.6.1" 


" : "You Know, for Search" 





图 15-7 


Kibana 以 Deployment 资源 运行 ， 用 户 可 通过 Service kibana-logging 访问 其 Web GUI. 
这 里 已 经 将 Service 的 类 型 修改 为 NodePort， 如 图 15-8 所 示 。 


:=$ kubectl get --namespace-kube-system deployment kibana-logging 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

kibana-logging 1 £ 1 1 21т 

ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system pod -l "k8s-app-kibana-logging" 


NAME READY STATUS RESTARTS АСЕ 
kibana-logging-7879c88776-sfhnv 1⁄1 Running 0 21m 
ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system service kibana-logging 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
kibana-logging NodePort 10.103.43.140 <none> 5601:30319/TCP 21m 
ubuntu@k8s-master:~$ 





图 15-8 


通过 http://192.168.56.106:30319/ 访问 Kibana， 如 图 15-9 所 示 。 
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etes 集群 日 志 管理 








€ > C [© 192468.58.106:30319/app/kibana#/management/kibanafindex? 





Management / Kibana 
Index Patterns Saved Objects Reporting Advanced Settings 


жы, Streep vos Configure ап index pattern 
contis: In order to use Капа you must configure at least one index д 
Dashboard. against. They are also used to configure fields. 
Index pattern sovanced options 
logstash-* 


Patterns allow you to define dynamic index names using * as a wildcard. 


Timelion. 


Machine Learning 


шу Time Filter field name Ө refresh бе: 
Dev Tools. timestamp 


Management Expand index pattern when searching [DEPRECATED] 


With this option selected, searches against any time-based index patterr 
Currently selected time range. 


Searching against the index pattern logstash-* wil actually query Elastic 
Wah recent changes to Elasticsearch, this option should no longer be ne 


Use event times to create index names [DEPRECATED] 


图 15-9 











Kibana 会 显示 Index Pattern 创建 页 面 。 直 接 单 击 Create，Kibana 会 自动 完成 后 续 配置 ， 


如 图 15-10 所 示 。 


A ki Management / Капа 
"s ibana Index Patterns Saved Objects Reporting Advanced Settings 











кенш K logstash-* 
ШЕ 
[zre awal This page lists every field in the logstash-* index and the field's associated core type as recorded 
пане type of each field, changing field types must be done using Elasticsearchs Mapping АРІ 
Machine Learning fields (113) scripted fields (0) source filters (0) 
Graph Q Filter 
hr пате = type: — format- searchable © - 
Managemer @timestamp [E] date + 
MESSAGE string v 
MESSAGE keyword string v 
PRIORITY string v 
PRIORITY keyword. string v 
SYSLOG_FACILITY string v 
SYSLOG_FACILITY keyword string v 
SYSLOG IDENTIFIER. string v 
SYSLOG. IDENTIFIER keyword. string v 
Ja string ~ 
index string + 
-store number 
-source „source 
_9pe string ~ 
[E peer A 
图 15-10 


这 时 ， 单 击 左 上 角 的 Discover 就 可 以 查看 和 检索 Kubernetes 日 志 了 ， 如 图 15-11 所 示 。 
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图 15-11 


Kubernetes 日 志 管 理 系统 已 经 就 绪 , 用 户 可 以 根据 需要 创建 自己 的 Dashboard, 具体 方法 


可 参考 Kibana 官方 文档 。 
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小 结 


Elasticsearch 附加 组 件 本 身 会 作为 Kubernetes 的 应 用 在 集群 里 运行 ， 以 实现 集群 的 日 志 
管理 。 它 是 Elasticsearch、Fluentd 和 Kibana 的 组 合 。 
Elasticsearch 是 一 个 搜索 引擎 ， 负 责 存储 日 志 并 提供 查询 接口 。 
Fluentd 负责 从 Kubernetes 搜集 日 志 并 发 送 给 Elasticsearch。 
Kibana 提供 了 一 个 Web GUI， 用 户 可 以 浏览 和 搜索 存储 在 Elasticsearch 中 的 日 志 。 
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作为 Kubernetes 的 实战 教程 ， 我 们 已 经 到 了 该 收尾 的 时 候 。 

本 教程 涵盖 了 Kubernetes 最 最 重要 的 技术 : 集群 架构 、 容 器 化 应 用 部 署 、Scale Up/Down. 
滚动 更 新 、 监 控 检 查 、 集 群 网 络 、 数 据 管理 、 监 控 和 日 志 管 理 ， 通 过 大 量 的 实验 探讨 了 
Kubernetes 的 运行 机 制 。 

这 本 教程 的 目标 是 使 读者 能 够 掌握 实施 和 管理 Kubernetes 的 必需 技能 ， 能 够 真正 将 
Kubernetes 用 起 来 。 

为 了 达到 这 个 目标 , 每 一 章 都 设计 了 大 量 的 实践 操作 环节 , 通过 截图 和 日 志 帮 助 读者 理解 
各 个 技术 要 点 ， 同 时 为 读者 自己 实践 Kubernetes 提供 详尽 的 参考 。 

本 教程 对 读者 应 该 会 有 两 个 作用 : 


СТ) 初学 者 可 以 按照 章节 顺序 系统 地 学 习 Kubernetes ， 并 通过 教程 中 的 实验 掌握 
Kubernetes 的 理论 知识 和 实 操 技 能 。 

(2) 有 经 验 的 运 维 人 员 可 以 将 本 教程 当 作 参考 材料 ， 在 实际 工作 中 有 针对 性 地 查看 相关 
知识 点 。 


希望 读者 能 够 通过 本 教程 打下 扎实 基础 ， 从 容 地 运 维 Kubernetes ， 并 结合 所 在 公司 和 组 
织 的 实际 需求 搭建 出 实用 的 容器 管理 平台 。 
最 后 视 大 家 使 用 Kubernetes 愉快 ! 


